Почему IT проекты такие непредсказуемые?
Те, кто работал с разработкой программного обеспечения, знают, что проекты очень часто задерживаются и выходят за рамки бюджета. Почему человечество научилось предсказывать сроки завершения строек и других инженерных задач, но не разработки софта?
В традиционной инженерии работа выполняется по инструкции с минимальной вариацией. Условно говоря, “клади цементный раствор, смешанный в определенной пропорции с водой, на кирпич и сверху клади другой кирпич”. Строитель выполняет эту работу по четко определенному нормативу без каких-либо дополнительных решений на месте. Суммируем всю работу, требующуюся на постройку здания, добавляем чуток жира на риски и план готов.
В случае с софтом разработчикам приходится принимать сотни микро-решений для создания даже самой простой системы, т.к. нет такого понятия как объективно правильно написанный код. Так же, в любой системе очень много неизвестных, которые скрываются до тех пор, пока не начнешь программировать, так называемые “unknown unknowns”. Более того, код написанный в одном модуле влияет на то, что ты напишешь в другом, т.к. код взаимозависим. Неправильное решение сегодня может повлечь необходимость менять или даже переписывать другие части системы через месяц.
Продолжая аналогию с кирпичами, разработчики знают, что дом нужно строить из кирпича и в соответствии с конечными требованиями пользователя, но они сами выбирают размер кирпича, состав и толщину слоя раствора, а также инструменты, которыми они пользуются. В процессе кладки кирпича, они выясняют практическим путем как раствор взаимодействует с кирпичом и, если необходимо, меняют состав раствора. Так как на проекте обычно работают несколько программистов, мы имеем N человек принимающих десятки микро-решений тут и там + коммуникацию между ними. Энтропия (хаос), которая создается в процессе, нелинейна и растет экспоненциально с количеством людей и локальных решений.
Что мы получаем в итоге? Создание системы большим количеством людей несет в себе столько вариативности, что точно предсказать сроки и бюджет является невозможной задачей. Сроки обычно предлагаются на основе планируемой архитектуры, известной информации (чтобы минимизировать локальные решения) и интуиции разработчиков и менеджера, основанной на прошлом опыте. Как правило, эти прогнозы слишком оптимистичны, так как нам, людям, сложно предугадать насколько непредсказуемым будет процесс и учесть это в расчетах.
Я еще не нашел стопроцентную панацею для решения этой проблемы и, скорее всего, панацеи нет. Чтобы лучше планировать я развиваю интуицию посредством собственного опыта, общения с более опытными коллегами, чтения литературы/статей, тщательного анализа проблемных проектов после их завершения, а также стараюсь разбивать проекты на более мелкие подпроекты. Последний пункт очень важен — маленькую подсистему можно создать с меньшим количеством людей и быстрее, что значительно уменьшает непредсказуемость. Ну и, конечно же, важно просто принять сам факт того, что IT проекты — это хаос и выставить соответствующие ожидания с клиентами, начальством и другими стейкхолдерами.
