Коллективное воображение в ИТ: как менялись методологии разработки и кому они нужны

Коллективное воображение в ИТ: каскадная модель

Когда я начал карьеру в программировании 20 лет назад, «богом» была каскадная модель. Мы должны быи писать длинные спецификации, отполированные до последнего миллиметра, вплоть до каждого класса в Java. После того, как спецификации получал и утверждал клиент, начиналась разработка, по завершении которой клиент платил деньги. Тогда всё было проще — и все были счастливы.

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

Компания вскоре закрылась, но не стоит делать никаких выводов из этого.

Да пребудет с вами Agile: гайд по основным терминам + курсы.

По теме

Да пребудет с вами Agile: гайд по основным терминам + курсы.

Коллективное воображение: стартапы 2000-х

Я устроился в другую компанию, которая смогла занять свою нишу и имела кучу работы. Я был сотрудником номер 39. В компании не было никакой каскадной методологии. Стоит сказать, что с точки зрения методологии в компании в принципе ничего не было. Спецификации утверждали в ходе телефонных звонков, дизайн, прототип и образец ПО были неотличимы друг от друга. Это был хаос, который по любом направлению протеворичил всему, чему меня учили. Работы было больше, чем компания могла «переварить», и все соглашались с таким положением вещей.

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

Впрочем, коллективное воображение работало — просто это не озвучивалось:

• у нас никогда не будет сформулированной миссии;
• нам не нужен HR или внутренние коммуникации, у нас есть паб (сложная задача для сотрудников с семьями);
• мы нанимаем только лучших.

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

Оказалось, что существует «быстрая разработка приложений» (RAD) с акценом на прототипировании. Клиентам говорили, что в компании используют RAD, и они были довольны.

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

Да, мы снова вернулись к каскадной модели, но на этот раз рабочие циклы были меньше и быстрее, к чему добавлялись те же проблемы изменения требований со стороны клиента, как и раньше. Был ли это «Водопад» на самом деле? Мы не знали.

Ещё один продукт воображения: Agile

Я начал слышать слово Agile в 2003 году. Иногда я спрашивал об этом людей, которые утверждали, что знают, о чём речь, — и их ответ в большинстве случаев очень быстро становился бессвязным. А те, кто действительно разбирался в проблеме, казалось, неспособны реально справляться с настоящим давлением со стороны проблемных клиентов, расписания и активных скептиков. В целом, мы продолжали работу со спецификациями, с некоторыми вкраплениями аджайл-терминологии. Собрания теперь называли «скрамы», но в остальном всё было как и прежде.

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

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

Вы не верите?

Я не хочу разбивать никакую из этих парадигм, потому что в этом нет никакого смысла. Если бы методологии разработки ПО не существовали, их нужно было бы выдумать — как ещё организовать эффективную совместную работу? Все эти условности нужны, чтобы эффективно работать в средних и крупных компаниях. Неслучайно парадигма Agile в чём-то имеют полурелигиозное влияние на команды.

Часто при обсуждении аджайла за пределами маленькой команды ощущается напряжённость. Когда я вижу нарисованный кем-то неизвестным мотивационный постер, который советует «избавиться от блоков», тогда как эти блоки внешние и необсуждаемые, что ещё мне делать, кроме как рассмеяться?

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

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

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

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

По теме

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

Почему не говорить о вещах открыто?

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

Создать полезную методологию разработки ПО нелегко. Сложность состоит не в её определении, а в том, чтобы убедить других следовать ей. Значительная чать истории разработки ПО крутится вокруг вопроса как убедить инженеров верить в конкретные истории про эффективность обязательных собраний, очки за пользовательскую историю, график выполнения работ и подготовку списка требований к ПО. Однако в случае внедрения методологии дают компаниям большую силу, так как позволяют распределённым командам взаимодействовать и работать, создавая продукт. Представьте, как сложно было бы создать Microsoft, Google или IBM, если бы обсуждать можно было только конкретные технические вопросы (автор перефразировал абзац из книги Sapiens — dev.by).

Нужны ли миру новые методологии? Кажется, многие весьма умные люди уже задавались этим вопросом.

Принятие

Lean, Agile, Waterfall — неважно. Факт в том, что для взаимодействия в больших командах нужна общая методология. Ни одна из существующих не является злом, поэтому речь не о том, выбрать ли коммунизм вместо фашизма или наоборот. Любая из них не будет отражать реальность, и каждый, кто ожидает увидеть идеал, явно будет разочарован. И следите за наличием непроговоренных результатов коллективного воображения. Жизнь наполнена ими: например, что ваше мнение важно.

Место солидарности беларусского ИТ-комьюнити

Далучайся!