bash.im
ithappens.me
zadolba.liПроцесс разработки программного обеспечения делится на четыре главных стадии: планирование продукта, разработка, тестирование, внедрение (то есть распространение, продажа, снятие сливок) — то, ради чего вся бодяга и затевалась. Если пропустить хоть одну стадию, продукт до конечного потребителя не дойдёт. Важное уточнение: момент перехода от одной стадии к другой необратим. Нельзя во время разработки менять планы этой же версии. Нельзя во время тестирования заниматься разработкой. Это краеугольный камень всей науки о создании программ.
А теперь — собственно, рецепт.
Стадия планирования. Планировщики строят какие-то планы. Менеджмент эти планы утверждает, планы передаются отделу разработки.
Стадия разработки. Все работают согласно приготовленным планам.
Стадия тестирования и стабилизации. QA проверяют функциональность, согласно утверждённым планам, находят какие-то баги, разработчики их чинят.
Две недели до выхода Release Candidate. Приходит крутой спец из отдела продаж и говорит: «А я тут был на презентации конкурента, у них такая классная фича есть! Давайте, чтобы быть конкурентоспособными, мы забацаем вот эдакую фичу? Продаваться наш продукт будет в …дцать раз лучше! А без неё этот наш продукт вообще никто не купит».
«У-у-у… Без продаж нам будет туго. А давайте!» — соглашается менеджмент.
Планировщики ударными темпами вписывают фичу в готовые планы. Отдел разработки до сих пор вообще не поставлен в известность. Менеджмент даёт разрешение поменять готовые планы, что, в общем-то, нарушает все правила этики, логики и разработки ПО.
QA, скрупулёзно следуя планам, добираются до только что вписанного куска. Описанная в нём функциональность, естественно, не работает, потому что её никто не писал. Открывается баг на тему «Мегаважная фича не работает!!111»; ему присваивается экстравысшая категория важности.
Только тут разработчики офигевают от бага, смотрят в планы (которые не должны были меняться ни при каких условиях), офигевают ещё раз и интересуются: «Это ваще что было?! А нас кто-нибудь спрашивал?»
Всё это сопровождается беготнёй, мейлами через три континента, криками, воплями и инфарктами. Менеджмент убеждает разработчиков поднапрячься. Кого-нибудь делают крайним и спихивают весь проект на этого бедолагу. Он выполняет задачу, держась исключительно на кофе и на мотивирующих пинках начальства. Ну, как «выполняет»… За неделю трёхмесячный проект не написать. Поэтому пишется только good path, и новая фича будет работать, если пользователь ни в коем случае не попытается отойти от описанной в документах процедуры. Всё остальное (а 80% работы обычно занимает обработка граничных и нестандартных значений) закрывается заглушками — иногда прочными, иногда не очень. Поведение программы в том случае, если пользователь всё-таки отошёл от good path, вообще никем не гарантируется. Если повезёт, заглушка сработает, и пользователь ничего не заметит. Если не повезёт… Значит, не повезет. Программист сдаёт проект, получает премию и уходит спать.
QA берутся за тестирование, находят целую прорву багов, но все они уже не критические, и с ними можно жить. Как вариант — чтобы QA не портили статистику сонмами найденных багов, всю группу, занимающуюся тестированием этого куска программы, в полном составе отправляют в отпуск.
Менеджмент радостно объявляет о включении новой функциональности в продукт. Продавцы готовят новые буклеты. Все счастливы.
Клиенты получают новую версию программного продукта. Поскольку пользователь — это такое периферийное устройство хаотичного ввода, а инструкции написаны для дураков, от good path отходят почти все. В результате — разрыв шаблонов, потому что программа, в общем-то, очень неплохая, внезапно начинает вести себя как студенческая самоделка, стоит только воспользоваться одной из новых функций и проявить чуть-чуть изобретательности. Хорошо, если дело ограничивается разрывом шаблонов. Иногда разрыв шаблонов переходит в стадию разрывов контрактов.
До следующей версии разработчики отлаживают этого мегамонстра, написанного на коленке за неделю, и приводят его во вполне симпатичный вид.
За две недели до выхода следующей версии кому-нибудь из продавцов приходит в голову идея великой фичи, которая поднимет продажи в …дцать раз.
Резюме № 1: инициативных дураков из отдела продаж надо убивать-убивать-убивать Ржавой Секирой Ужоса, желательно сразу после их трудоустройства.
Резюме № 2: с момента начала разработки у планировщиков надо забрать физическую возможность менять планы этой версии.
Резюме № 3: менеджмент, который этого не понимает, ведёт компанию к краху.