О процессах

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

В новой, только что установленной версии системы заказчик попросил сделать минимальные доработки. Ушел запрос на нашего проектного менеджера, прошел положенные 5-6 уровней пересылки между менеджерами разного уровня с пометкой “Срочно оценить реализуемость!” и, наконец, попал на исполнителя-разработчика – моего знакомого.

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

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

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

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

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

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

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

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

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