Доверие

В этой заметке хочется поговорить о взаимном доверии во время процесса разработки.

Людям, особенно вашим коллегам нужно доверять. Доверять практически всегда: если что-то просите сделать, если спрашиваете сроки задачи, как дела, сложность текущего проекта. Но есть одно важное исключение.

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

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

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

Задача: нам здесь на лендинге нужно выводить табличку с вот такими и такими данными, которые бизнес хочет отображать.

Плохое решение: заводим в базе табличку со строками и полями как в ТЗ. Проксируем данные таблички на фронт как select * from table. Поля в табличке, АПИ бекенда и АПИ фронтенда полностью идентичны. Хочется повеситься написать генератор, потому что это уже моя седьмая задача по проксированию таблички в этом месяце.

Хороший процесс принятия решения: разбираемся, что там лежат за данные, как они будут формироваться. Будут ли их менять вручную или автоматически. Как часто они будут меняться. Узнаем? что это хардкод, менять будут раз в месяц в лучшем случае.

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

Такой подход к разработке очень требовательный.

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

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

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

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

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

А в маленьких - изменение ТЗ просто сжирает драгоценное время. Особенно в стартапах, которым для хорошего роста нужно тратить как можно меньше времени на переделки одного и того же. Стартапам нужно обгонять конкурентов и догонять больших неповоротливых ИТ гигантов.