Промышленное программирование и область ответственности разработчика

Промышленное прогаммирование

Хочу поделиться опытом промышленной разработки программного обеспечения. Под словом «промышленная» я понимаю разработку приносящего деньги продукта в коллективе от нескольких десятков человек.

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

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

Аджайл-манифест разработки программного обеспечения

Начнем систематизировать знания о разработке с аджайл-манифеста:

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Это емкие, многогранные принципы. Мы к ним еще не раз вернемся. А пока посмотрим на одну составляющую первого принципа, а именно на то, как организуют взаимодействие с разработчиком.

Область ответственности разработчика

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

Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тестировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.

Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!

Вторая:

Минус подобных разработчиков в том, что они реально хорошо работают только если все тщательно спланировано. в критической же ситуации они теряются и оказываются абсолютно неспособны срочно решить внезапную проблему.
…
Я хочу получать удовольствие от своей работы, я хочу того самого пресловутого творчества, новых идей и всего такого. если я не вовлечен в процесс, не принимаю участия в обсуждениях и просто плыву по течению бездумно делая что мне написали в тикет — какое от этого удовольствие? какое от этого ощущение своего вклада в итоговый продукт?

Это два противоположных подхода к вопросу об области ответственности разработчика. Давайте выделим особенности каждого подхода:

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

Руководитель программистов должен учитывать при подборе и огранизации рабочего процесса особенности каждого способа. Первый свойственен водопадной модели, воторй — аджайлу. Если вы нанимаете инициативных разработчиков — готовьте бюджет. Если нанимаете операторов ЭВМ, нанимайте еще менеджеров и тестировщиков.