Я много лет занимался чем-то в небольших группах. Дольше и плодотворнее всего в музыкальных группах и на работе (на работе я делаю интерфейсы к программам). И я давненько открыл один секрет, смотря, как работают другие, и как работаем мы, и к чему это всё приводит.

Так вот, секрет такой: нельзя ничего решать голосованием, нужно выбрать человека, который будет принимать решения и довериться ему.

Голосования приводят к спорам над каждой проблемой, длинным обсуждениям, уговорам сомневающихся, закулисным интригам, когда кто-то договаривается проголосовать так, как нужно одному из них. И каждое решение принимается через боль и через вечность. Так каши не сваришь.

В подходе с выбором ведущего важно, что у него появляются не только право принятия решений, но и обязанности: учитывать мнение каждого и нести ответсвенность за решения. Короче, процесс принятия решений происходит следующим образом:

• Опросить мнение у всех участников
• Придумать лучшее решение, учитывающее это мнение
• Рассказать о нём, услышать возражения, но только один раз
• Претворить решение в жизнь
• Нести ответсвенность за последствия решения и менять его при необходимости

Здесь не нужна какая-то формальность в пунктах и последовательности, нужно просто примерно понимать процесс.

А у всех других ребят остаётся право сменить этого человека на другого, если что-то раз за разом не нравится.

Ещё очень круто, если такими лидерами становятся все в группе, но только в своей сфере: кто-то отвечает за одно, а кто-то за другое. Особенно это круто тогда, когда нужно принимать много решений, а ещё хорошо потому, что каждый чувствует и личную ответственность тоже.

Короче, никакой прямой демократии, только представительная. Думаю, что и в больших группах всё так же.

P.S. На всякий случай отмечу, что я много раз был как и тем, кто принимает решения, так и тем, к мнению которого просто прислушиваются.

Разберём случай, когда до дизайнера или разработчика доходит какая-то задача, сформированная цепочкой менеджеров и аналитиков по чаяниям заказчика на конкретном примере.

Возьму пример из области медицины, в которой проработал несколько лет. В общем смысле задача обычно звучит как-то так: «Отобразить список свидетельств о рождении, которые регулярно приходят из медицинских организаций.»

Обычно до разработчика доходит какая-то такая задача:

«Необходимо создать страницу с отображением всего списка свидетельств, с возможностью изменения набора столбцов и фильтров. Изначальные наборы столбцов такие-то, наборы фильтров такие-то. Обеспечить разный уровень доступа для разных пользователей, возможность создания и подписания новых документов, выгрузки в EXCEL, XML, CSV, PDF, Word сохранения истории изменений. Ктопку такую-то разместить здесь, такую-то здесь, вот эту сделать зелёной. Набор полей документа формируется с учётом ФЗ № такой-то такой-то, ...»

И так ещё 10 страниц. Это совершенно ужасная постановка задачи, которая одновременно подразумевает, что дизайнер или разработчик тупой, как дрова, и может действовать только по алгоритму. И с другой стороны, она перекладывает на разработчика самые ресурорсоёмкие операции, как, например, поиск набора полей в каком-нибудь приложении к федеральному закону.

Разработчику говорят, что делать, но не говорят, почему. Нет ответов на следующие вопросы:

• Почему мы вообще это делаем? Какую проблему заказчика мы решаем?
• Зачем нужна возможность изменения набора столбцов и фильтров?
• Что значит разный уровень доступа? Кто вообще будет этим пользоваться и в каком случае?
• Каким образом должна быть реализована подпись? Физическим ключом в USB? Паролем? Электронной подписью?
• Что значит «отображение всего списка свидетельств»? Сколько их всего? А если несколько миллионов? Вы уверены, что кому-то нужно сразу видеть миллион свидетельств за несколько лет?
• Выгрузка миллионов записей из БД с внешними ключами и данными из других таблиц и форматированием в каком-то формате займёт очень много времени и сильно нагрузит базу. Существует ли реальный сценарий использования этой функции?

Ну и так далее. Зато есть ненужные подробности о расположении кнопок и перечисления «как бы» форматов файлов выгрузки. Конечно, здесь очевидно, что менеджеры не смогли узнать реальную проблему заказчика и как решить именно её имеющимися средствами.

Неопытный разрабочик просто возьмёт это в реализацию не думая и начнёт программировать шаг за шагом. Задача окажется трудновыполнимой даже за несколько месяцев (что его тоже не побеспокоит), всё будет тормозить потому, что для такого общего решения недостаточно просто добавить индексы в БД, чтобы всё работало быстро, и в конце концов, когда задачу покажут заказчику, у него полезут глаза на лоб и он удивится, как такую неповоротливую махину можно было делать несколько месяцев, когда она всё равно не работает, потому, что оттестировать все варианты поведения и отображения такой махины невозможно.

Если же пообщаться с заказчиком, слушая не только предложенное решение, а ещё его проблемы, то всё станет на свои места. Окажется, что с этим списком должны работать такие-то врачи и работники загса. Что права на изменение и добавление такие-то. Что любые поля нужно отображать, чтобы было видно, отфильтровалось или нет (конечно, здесь нужно придумать другое решение), что вывод всех документов сразу не нужен, а нужен в разрезе по медицинской организации.

Такую задачу уже можно сделать за неделю, и, даже если какие-то из требований были описаны неверно, у нас есть ещё много времени, чтобы это исправить.

А может оказаться, что сегодняшнего списка документов любых типов с фильтрацией по типу уже достаточно для решения этой задачи и нам не нужно делать ничего, кроме настройки шлюза для получения этих документов от медицинских организаций. Вот и экономия месяцев труда команды на пустом месте.

Когда я собрался увольняться из компании, в которой вёл большой проект со стороны интерфейса, к нам пришёл молодой разработчик сразу после университета. Он не знал конкретных библиотек, которые мы использовали.

За этот месяц я рассказал ему, что необходимо, и он довольно быстро включился в процесс. По прошествии нескольких месяцев, бывшие коллеги рассказали мне, что так получилось, что сейчас он единственный поддерживает разработку интерфейса этого большого проекта. И что разработка идёт вполне себе устраивающими темпами.

У него есть мои контакты, но он ни разу мне не писал. Конечно, он может спросить что-то у коллег, но и они говорят, что он не так часто это делает.

И это комплимент для меня. Если большую систему с сотнями представлений и страниц можно успешно поддерживать не имея большого опыта, то это значит, что та архитектура, те принципы, которые были использованы были правильными.

Однажды ко мне пришёл менеджер и сказал, что нужно сделать развёрнутую систему прав. Я был ведущим разработчиком на проекте, у меня оставалось два дня до отпуска, а систему прав нужно было выпускать через 2 недели, когда я ещё буду в отпуске.

Я задумался. К тому времени у нас была очень простая система прав. У нас было что-то вроде 7 разделов и если кто-то имел доступ к разделу, то мог делать в нём всё. Теперь требовалось сделать так, чтобы для разных пользователей были доступны или нет конкретные действия и кнопки: просмотра, редактирования, удаления.

Но были и плюсы:

• мы уже обсуждали будущую необходимость появления системы прав с бекэндером и он знал, как это можно сделать;
• мы никогда не опирались на то, что фронтенд сам что-то контролирует, поэтому запрет редактирования заключался не в скрытии кнопочки, а в том, что и по API редактирование не будет доступно;
• у нас были конфигурации каждой страницы. Страницы были описаниями какие данные где взять и как их отобразить, а не вёрсткой каждой страницы отдельно;
• в начале проекта я настоял на том, чтобы каждая страница отображала одну сущность, или один набор сущностей. К примеру, кнопка удаления была только на странице редактирования документа, а не где-то ещё. Запретив переход на эту страницу мы автоматически запрещали и редактирование, и удаление. Сделал я это исходя из удобства пользователю, но оказалось, что это удобно и нам.

Я написал за несколько часов заглушку бибилиотеки, проверяющей права. Договорился с бекэндером о том, в каком формате он будет присылать список прав для каждого пользователя. И рассказал своей команде, что именно нужно делать для того, чтобы всё заработало.

И пошёл в отпуск.

Когда я вернулся, система была готова и выпущена, в отпуске меня никто не тревожил, а ребята смогли придумать пару вещей, о которых я не успел подумать до отпуска, но которые несколько улучшили систему.

Я обрадовался. Если ребята могут это сделать без меня, то значит, что код, который я написал понятен, подход, который я предложил тоже, подготовка ребят достаточная, а я могу не тратить время на такие задачи и переходить на ещё более сложные.

А вот если бы мне каждый день звонили в отпуске, то это бы значило не то, что ребята не знают границ, а то, что я недостаточно хорошо объяснил и подготовил работу.

Сделали мы новый проект и пришло время его тестовой эксплуатации.

В компанию приехал технический пециалист заказчика и стал задавать всякие каверзные вопросы. Сначала с ними справлялся менеджер, но в какой-то момент перестал и в кабинет позвали меня, как ведущего разработчика проекта.

Представитель заказчика задал какие-то вопросы, о которых мы подумали и на которые я знал ответ и вот прихоло время следующего вопроса. Он говорит:

• Вы сделали прекрасную историю изменений, которой нет у конкуретнов. Теперь в истории хранится не только время и автор изменения, но и весь слепок версии на то время. Однако, мы боимся, что документы будут меняться часто и история начнёт занимать слишком много места за года использования. На основном сервере мы не можем обеспечить столько места на жёстких дисках, и хотели бы вынести историю в отдельную базу на другом сервере. Можно ли так сделать? Сможете ли вы это запрограммировать?

В моей голове завертелось следующее:

• проблема есть;
• выносить в отдельную базу, значит, потерять внешние ключи, это значит, что мы не сможем контролировать целостность, и, наверно, появятся ещё какие-то проблемы;
• программировать что-то для частного случая не хочется, так мы можем придти к 15 БД;
• любое программирование — это деньги компании и мне придётся объяснить, почему мы это делаем;
• эта проблема точно возникала не только у нас, множество продуктов хранят историю и вообще очень много данных;
• мы используем PostgreSQL, это наиболее развитая свободная СУБД и там точно есть решения для этих проблем, когда данные не помещаются на один жёсткий диск.

И я сказал: я думаю, что нам не нужно будет ничего программировать. Мы сможем вынести таблицу с историей на другой сервер посредством возможностей СУБД.

Представитель удивился, сказал, что хорошо, если так и я пошёл на рабочее место. Там я спросил у бекэндера, был ли я прав. Он ответил, что да, и что это называется «внешние таблицы».

Мораль в том, что проспо подумав и прикинув вероятность того, что что-то работает так, как тебе нужно, ты можешь придумать решение для разных ситуаций. Правда для этого нужен какой-никакой кругозор.

Поэтому я и трачу существенную часть рабочего времени на то, чтобы этот кругозор нарасти и не потерять.

Однажды на работе мне дали задачу сделать новый продукт вдвоём с бекэндером — он делает всё, что на сервере, я всё, что в браузере. И этот продукт должен стать платформой для других новых продуктов. Впрочем, я и сам подводил к тому, чтобы эта задача досталась мне.

К тому времени текущие продукты были сделаны на смеси Java + Spring + Angular 1 + JQuery. То есть на сервере хранились .jsp-странички к которым были подключены JS-библиотеки, лежажие прямо здесь, устаревших версий, в которых предыдущие программисты ещё что-то меняли руками, поэтому обновлять их не было никакой возможности.

К тому времени я начитался в интернете о том, что существует какой-то npm-репозиторий с библиотеками, что есть React.js и какие-то другие фреймворки, что есть какой-то компонентный подход, который используется в новом Angular 1.5 в том числе. Ещё мне откровенно не нравилась Java на бекэнде. Мне представлялось, что у нас вырос какой-то невероятный энтерпрайз-монстр, который в первую очередь обслуживал сам себя, а не мифическую высокую нагрузку.

Если вы не фронтенд-разработчик и не поняли, что написано выше — неважно. Важно то, что я понимал, что сегодняшняя архитектура неимоверно сложна, что есть пути проще и популярнее, и что я совершенно не знал, работают ли они.

И с этим всем я пошёл на совещание с директорами, для того, чтобы мы с бекэндером представили новый подход к технической платформе. Там мы рассказали об этих новых способах, получили согласие и разошлись работать. На совещании с нами сидел опытный фронтендер, который не занимался этим проектом, но мог что-то прокомментировать. Он сказал мне несколько слов уже после совещания. Они были такими: «У тебя не получится так сделать».

И вправду, я и сам был не уверен в том, что у меня получится, я же не делал такого никогда. Я был уверен только в том, что другие так делают и у них получается и в том, что не боги горшки обжигают.

Всё закончилось хорошо. Продукт мы разработали в срок, на его основе выросли огромные проекты.

Подобные вещи случались многократно, каждую неделю мне нужно было делать что-то такое, что ни я, ни кто-то другой в компании не делал.

И в этом и суть. Ты растёшь сам и помогаешь расти компании только когда берёшься делать то, в чём совсем не уверен, что справишься.

Если ты делаешь многократно что-то, в чём уверен, то нужно либо передать эту работу молодому коллеге, или автоматизировать, чтобы не топтаться на одном месте.

Часто люди пытаются сделать даже промежуточные работы и отчётами идеальными. Прорисовывают каждую деталь, делают аккуратно, запариваются о пикселях и так далее. Так не надо. А надо так, чтобы решало задачу.

На работе мы часто обмениваемся скриншотами, на которых помечено куда смотреть. Часто люди ставят специальные программы и следят за тем, чтобы их подчёркивание или выделение были ровненькими. А нужно так:

Притом так даже лучше, чем когда ровненько: ты сходу понимаешь, что выделение — часть скриншота, а не самого интерфейса.

Или, например, при работе над дизайн-проектом можно сначала сделать коллаж из мебели, а не 3D-визуализацию. Прикинуть, как будут сочетаться цвета и мебель по нему можно, исправить будет легко, а силы на визуализацию не будут потрачены.

Так что не только можно, а нужно делать меньше.

Когда мы играли в музыкальной группе, то часто через час репетиции менялись местами. Гитарист — за барабаны, вокалист — за бас, басист за гитару и барабанщик на вокал. Ну или как-нибудь по-другому.

И так мы играли пару песен. Получалось, конечно, паршиво, но суть не в этом. А в том, что в такие моменты можно лучше понять, что именно делает другой человек в группе, как он это делает, что важно и что нет, а ещё понять, что другие-то тоже нехило так стараются.

И так, конечно, стоит делать в любом коллективе.