Карго-культ в разработке ПО

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

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

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

На текущий момент доступно множество инструментов, которые позволяют описывать инфраструктуру проекта(сервисы, сети, зависимости) в удобной форме, например, Terraform. Вещь эта безусловно полезная, но с некоторого размера проекта, например, когда он становится достаточно сложным. Для большинства стартапов и небольших проектов, это избыточный инструмент, так как инфраструктура меняется крайне редко, а возможность быстро разворачивать еще один Production нужна, грубо говоря, раз в год, многие стартапы могут просто не дожить. Поэтому, чем проще описан проект - тем лучше, многим будет достаточно и Docker Compose.

Чрезмерное увлечение тестами приводит к тому, что на это расходуются драгоценные ресурсы разработки, значительно увеличивает стоимость рефакторинга(ведь надо переписать все затронутые тесты) и часто создает иллюзию надежности кода и правильности его работы. Я встречал стартап, где после года разработки было написано более 2000 тестов только для backend!

Чтобы эффективно двигаться вперед по разработке, тестами нужно покрывать только действительно важные участки кода, где выполняются какие-то вычисления и диагностика вручную ошибок затруднена. Часто для стартапов покрытие тестами можно отложить до момента, когда структура кода станет стабильной, а бизнес-логика станет ясной и вряд ли существенно поменяется. Для frontend unit-тесты зачастую малоэффективны, так как сложных вычислений и алгоритмов, обычно, там мало, а покрывать базовую функциональность SPA типа нажатий кнопок лучше на этапе BlackBox-тестирования через Selenium или им подобным.

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

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

Часто такие CTO любят говорить, что у них все - Fullstack developers, хотя лично я крайне редко встречал одинаково сильных на frontend и backend, слишком много технологий нужно знать на хорошем уровне.

Всегда критически подходите к вводу новых сущностей(сервисы, технологии). Если в Вашей команде есть люди, хорошо знающие MySQL, но не работавшие с Postgres, то нет смысла выбирать Postgres, если это не дает Вам значительных преимуществ. Процесс разработки должен быть адаптирован под команду и бизнес. Если Вася работает по Scrum и покрывает все юнит-тестами, это не значит, что этот подход сработает и у Вас, нужно всегда критически оценивать и сравнивать с другими вариантами(Waterfall). Выявляйте сильные стороны у членов команды и используйте их по максимуму. Это повысит эффективность работы всей команды, а сотрудники будут более счастливы, ведь они приносят больше пользы за меньшие усилия.