Как хорошему разработчику не стать плохим менеджером

Стоимость ПО ничтожна по сравнению с общей ценой изделий.

В цифровых продуктах аналогично. Instagram в 2012м году был приобретён Facebook, и примерная стоимость сделки составила $1 млрд. Стоимость собственно разработки несравнима с этой суммой. Стоимость компьютерной графики фильма “Миссия невыполнима – 2” не идет ни в какое сравнение с гонорарами Тому Крузу. Хотя его можно было бы просто нарисовать.

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

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

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

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

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

2. У заказчика нет времени на уточнение требований. Изменение требований в процессе разработки ПО сейчас настолько распространено, что The Standish Group изменила критерии провала проекта для своего Chaos Report. Если клиент доволен, то считается, что проект успешен, несмотря на то, что сделали не то, что планировали.

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

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

проект пройдёт по плану абсолютно никаких.

Хорошая новость заключается в том, что заказчики это понимают (обычно).

Большинство заказчиков имеет возможность увеличить бюджет или убрать часть функционала, чтобы проект таки принёс им какой-то осмысленный результат.

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