Есть такая старая и популярная до сих пор теория, что любой проект можно представить как взаимосвязь трех переменных: фронта работ (scope), временных затрат и финансовых расходов. Применим ли треугольник в современном мире, попытаюсь разобраться в заметке.

Что

Суть теории в том, что три переменные (фронт работ, время и деньги) в проекте жестко взаимосвязаны и могут быть представлены в виде треугольника.

Насколько я понимаю, оси треугольника расходятся из центра и под "увеличением" имеется в виду удаление от центра. При этом значения двух других переменных считываются через длину сторон треугольника.

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

В чем теория права

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

Что с этой теорией не так

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

В частности, зависимость стоимость и времени не так очевидна.

Что происходит на практике с временем-стоимостью

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

По порядку разберемся с каждым из тезисов.

Почему дешевле сделать проект быстрее

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

Почему иногда нельзя просто взять и растянуть проект

• Финансирование может быть ограничено по времени (как было в нашем случае).

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

• Технологии "гниют".

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

• Конкуренты тоже работают.

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

• Ниша может перестать существовать.

Как в случае с пандемией - многие бизнес-решения можно было провернуть только в определенном временном окне. Так сделал, например Zoom, получивший дикий буст роста в результате массового ухода на удаленку. В конце пандемии подтянулись тех-гиганты со своими решениями (Google Meets, Microsoft Teams) и если бы Zoom решил удлинить разработку, конкурировать им было бы гораздо сложнее.

Почему сложно ускорить разработку деньгами

Если анализировать время написания кода или создания контента, достаточно непросто ускорить данные работы простым увеличением финансирования.

• Большее количество программистов требует большей слаженности.

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

• Не каждый программист приносит пользу в проект.

И выяснить это бывает непросто на собеседовании и даже в первые недели работы. Я не говорю, что это невозможно - хорошие рекрутеры отфильтруют кандидатов на самом первом этапе, а грамотный техлид выявит некомпетентных за один спринт. Но для этого нужен опытные рекрутер и техлид, чего у небольших стартапов может и не быть.

• Дополнительные сотрудники вне контекста.

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

• Платить больше программистам не увеличит количество и качество их кода.

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

Примеры из практики

• Пример #1: студенты-авторы

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

Наш выигрыш был незначителен, т.к. примерно половина студентов работала неэффективно.

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

Да, мы в итоге выиграли немного времени, потратив какое-то количество денег, но мы позволили себе это сделать только потому что средства эти в противном случае были бы просто возвращены - статьи расходов в государственном проекте были жестко прописаны и ни на что другое, кроме сотрудников, мы их потратить их не могли.

• Пример #2: джун-разработчик

В нашей команде было два фронтендера - один для андроид-разработки, другой для iOS. И если с iOS всё шло быстро (спасибо Apple за качественные инструменты разработки и вменяемые гайдлайны), андроид нас сильно тормозил. Мы очень зря связались с Flutter от гугла, но это другая история.

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

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

В результате мы более-менее верно определили узкое место, но, видимо, не совсем правильно с ним поработали.

Что я понял

Что я выучил из этих двух примеров?

• Рекрутингом должны заниматься рекрутеры.

Тимлид или даже техлид не может эффективно отбирать кандидатов.

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

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

В идеальном мире и в идеальной организации всё вышенаписанное должно быть, конечно, иначе. На практике мы работаем с тем, что есть.

• Дублирование функции сотрудников не самый эффективный способ увеличить скорость разработки.

Я попытался решить проблему брутфорса - что не может сделать быстро Х-сотрудников, мы попробуем решить с помощью, условно, 2Х-сотрудников.

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

• В первую очередь проект-менеджер должен разгружать себя.

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

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

• Устаревшие методы работы в организации могут подорвать любые попытки оптимизации.

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

Например, фазы проекта разработки установлены жестко, хотя о разрабатываемом продукте не известно ровным счетом ничего. Или позиции расходов в бюджете прописаны заранее и любое изменение требует ЧРЕЗВЫЧАЙНО больших затрат времени на их согласование, хотя, опять же, даже требования конечного продукта на этапе планирования не были описаны более-менее конкретно.

Также имеет значение способность людей использовать технологии оптимизации. Например, вне нашей команды мы никого так и не смогли заставить работать с коллаборативными инструментами. То, что умеет делать каждый школьник - открыть по ссылке документ и внести прямо в него правки, слишком многие в Германии делать не то что не привыкли - они всячески этому противятся. Ретрограды и луддиты, сидящие на своих местам десятилетиями и видящие, что вроде как их проекты как-то там развиваются, зачастую просто не способны воспринимать информацию. Ситуация ещё более усугубляется параноиками в отделах цифровой безопасности, единственным методом работы которых является написание протоколов типа "никаких облаков, никаких флэшек".

Какие проблемы все-таки можно попытаться решить деньгами

• Закупка оборудования

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

• Аутсорс

Некоторые задачи можно переложить на внешних подрядчиков, но нужно иметь в виду, что аутсорсеры немотивированы ничем, кроме чека, находятся вне контекста и требуют регулярного контроля. Иначе получится Warcraft III: Reforged.

• Закупка софта

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

• Закупка технологий

Вместо того чтобы что-то разрабатывать, часто можно купить кусок технологии или технологию целиком. Это врядли применимо к стартапу, но является очень эффективным вложением. Крупные корпорации покупают целые компании и команды, хотя казалось бы могут разработать аналог самостоятельно. На небольшом масштабе подобное доступно и менее крупным игрокам, благодаря массовости распространения микросервисов, доступности гранулированных и скалируемых серверных услуг и т.п.

• Оптимизация процессов за счет найма сотрудников сопровождающих разработку (девопсов, скрам-мастеров)

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

Выводы

• Теория треугольника проект-менеджмента это частный случай теории ограничений, имеющая право на существование.
• В треугольники три вершины - фронт работ, расходы и время. Каждая переменная является зависимой переменной.
• Изменение одной переменной влечет за собой изменение как минимум одной другой.
• Однако, взаимосвязь стоимости и времени может быть не такой очевидной и работает для разных компаний по-разному.
• Крупные компании и/или опытные проект менеджеры способны закидать деньгами определенные узкие места (через закупку оборудования, технологий и специфических сотрудников).
• Небольшие компании или начинающие команды скорее должны рассчитывать на свои силы и регулировать сроки и стоимость через фронт работ.
• Застарелые ретроградские организации с их луддитскими подходами к работе не спасти.

EVOpit.log

https://t.me/evopit:

Хроника продвижения по карьерной лестнице магистра биомедицинской техники.

Бонусом: концентрат трансгуманизма, гаджетов, биохакинга и прочего повышения продуктивности.