Все статьи
Логическое И в государственных контрактах
Дата: 29.03.2024
Алексей Колегов (ООО УК «Роснано»), Михаил Иванов (ООО «ПроАктор Солюшнс») и Ольга Щелконогова (ООО «ПроАктор Солюшнс»), рассказали про управление проектами по отклонениям сроков/бюджета/результата при ежемесячном выставлении заявок от заказчика и оценку их подрядчиком в рамках ФЗ-223 и согласовании функциональности с заказчиком уже на этапе прототипирования, благодаря возможностям low-code платформы.
Алексей Колегов: Что касается госзакупок, для меня эта история очень комплементарна с крупными компаниями, когда есть все процедуры, максимально жестко стараются на закупку завести техническое задание. Как правило, в его составлении участвуют не те, кто потом будет пользоваться продуктом. Когда в одной из крупных компаний мы попытались согласовывать функциональные требования с функциональным заказчиком, это превратилось в ад. Потому что с одной стороны функциональный заказчик или ключевой пользователь не понимает вообще, как то, что написано в этом документе, будет происходить в его жизни. Человек старается, мучается, читает документ, все равно его не понимает. Рядом стоят айтишники, которые писали этот документ и говорят: «Ответственность-то тебе за это брать. Ты либо подпишешь, либо мы ничего не закупаем».
К чему это по итогу приводит? Вот так выглядит функциональный заказчик, так выглядит IT-партнер, IT-директор и подрядчик, который по результатам исполнения этого контракта и попыток с него получить все то, что написано в ТЗ чаще всего «умирает».
Есть определенная нелюбовь к крупным заказчикам и государственным контрактам среди моих коллег, которые находятся на стороне заказной разработки и это заключается в том, что они выжмут потом все до последнего. Что можно предложить, чтобы этого избежать? Предложить можно только одно. Работать командой, выбирать, с кем работать. Как Михаил говорит часто, работаем мы все-таки с людьми и контракты и проекты мы выполняем с людьми.
Много лет назад я познакомился с методологией PRINCE2. В 1989-м году в Великобритании, по той информации, которой я владею, начали применять эту методологию. На сегодняшний день очень много европейских стран применяют эту методологию в качестве государственного стандарта и де-факто стандарта исполнения проектов.
Чем мне понравилась эта история? Я про нее сейчас всё рассказывать не буду, просто чтобы было понимание на те отсылки, которые дальше буду делать. Это разделение на стадии, понятно, про что мы говорим, водопад. Но здесь еще есть понятие управления по отклонениям. В отличие от нашей стандартной триады «сроки, качество, бюджет», в методологии еще предполагается, что есть некоторые другие результаты проекта, которые не всегда очевидны. Меняются процессы, либо они появляются. Появляются изменения, которые в явном виде не предусматривал проект, но они тем не менее все равно происходят. Есть понятие организации и есть понятие уровней проекта. На верхнем уровне дирижирования находится совет или комитет проекта. Далее идет управление. Это вся та кросс-функциональная команда, которая выполняет проект и им управляет. И ниже идет уровень delivering. Это команды, которые непосредственно выполняют результат, обеспечивают его доставку.
На примере той триады, которой мы все-таки привыкли оперировать, я пытался показать, что полезного в этой методологии для меня нашлось. Это управление по отклонениям. То есть методология все-таки не стандарт. Она позволяет вообще не задумываться о процессе закупки и сосредоточиться на управлении проектом.
Как это можно применять? С уровня компании, когда идет планирование получения какого-то результата, все откровенно и открыто друг другу говорят, что нельзя планировать в конкретный срок, должен быть буфер. И вот этот буфер, это тот резерв, который есть у компании на управление теми изменениями, которые в процессе проекта возникнут. Дальше этот резерв спускается на уровень ниже совету проекта, управлению проектом, командам проекта. И все откровенно понимают, что те сроки, которые называются, тот бюджет, который называется, и те результаты в виде конкретных функций, которые мы ожидаем от проекта имеют какую-то дельту. То есть тот люфт, который находится в зоне управления команды.
Что важно? В менеджменте есть такое правило: «уперся – доложи». Важным является доверие между этими уровнями. Те кто на нижележащем уровне или вышележащем уровне, узнают о каких-то изменениях, которые влияют или могут повлиять на результат, срок, бюджет, должны об этом проинформировать других участников на других уровнях. И в этом случае, даже если команда допускает пробой, съела весь свой резерв, получила пробой срока, но этот срок, когда он поднимается вверх и обратно декаскадируется, получается, что на уровне совета проекта либо на уровне компании этот срыв не является критичным, потому что он находится где-то в промежуточном этапе и по масштабам общего таймлайна укладывается в те допуски, которые были разрешены, например, управлением проектом.
Вот эта история с точки зрения сроков, думаю, всем понятна, с точки зрения бюджета тоже объяснима, но с точки зрения результата возникает вопрос: «Как управлять результатом?». Для себя мы разделили результат на три уровня. Это архитектурное решение, функциональность, и фичи, «плюшечки», которые нам были бы полезны и по ходу проекта они возникают. Если у нас все в графике, если у нас все в бюджете, то команда берет на себя добровольно инициативу путем добавления того функционала, который не является обязательным, но по ходу проекта показался нам интересен. Перекрасили кнопки, переставили их местами, сделали объединение форми так далее.
По коммуникации. Почему управление по отклонениям? В любой момент возникающего отклонения оно транслируется наверх. Соответственно, между командой, которая непосредственно является исполнителями по проекту и управляющим органом проекта, кросс-функциональной командой, всегда должна сохраняться коммуникация. Методология описана в виде форматов записи и так далее, но сейчас нам не это важно.
Нам важно, что, в первую очередь, спускаются не требования, а спускаются ожидания в команду. Команда берет оценку этих ожиданий и уточняет те границы, которыми она обладает. При этом команда однозначно заявляет те допуски, которые она на это берет. После чего получает подтверждение, что предложение от команды релевантное и удовлетворяет ожидания. Результат уже отдается с учетом всех допусков и с учетом ограничений. Это не значит, что должен быть получен результат один в один. Это значит, что мы определяем рамку и недопустимые, либо допустимые варианты реализации.
Вариант формирования бюджета. Первое, что возникает у меня, когда оцениваю проекты, это как понять, сколько они будут стоить. Здесь есть математический подход. Мы всегда до встречи с ребятами использовали подход запроса предложений. Исходя из опыта, компетенции и доверия к тому или иному автору этого предложения проставляли весовку и находили что-то субъективное. Коллеги предложили нам вариант, как это можно делать более методично.
Ольга Щелконогова: Я немножко расскажу о нашем проекте, который в принципе длился недолго. Мы применили новые подходы, именно Agile-разработка, и в рамках 223-го ФЗ коллеги смогли реализовать наш проект, и мы приняли в этом участие. Модель непосредственно TM, когда мы используем заявки. Со стороны Минцифры, РТ Лабс заказчик определял стоимость работ, которые будут исполняться. У нас немного по-другому был реализован подход. Когда заказчик выставлял заявку, что необходимо, что нужно было сделать, мы уже декомпозировали, оценивали и совместно с заказчиком согласовывали данную оценку. У нас был общий объем проекта, в котором в рамках 223-го закона была определена сумма и сроки оказания услуг, и они все были разбиты на контуры. В рамках данных контуров создавалась ежемесячная заявка, где мы уже декомпозировали, согласовывали задачи, которые будут выполняться, оценки, продолжительность, сроки.
Благодаря нашей платформе, которую мы использовали, на которой все разрабатывали, было легко создать непосредственное прототипирование. Коллеги в прошлых докладах уже говорили о том, что они доходили до уровня тестирования, и тогда у них возникали проблемы с функциональным заказчиком, с реализацией, мы смогли на этапе реализации, прототипирования непосредственно уже согласовывать ту функциональность, которая должна быть.
На основе данных прототипов дальше реализовывался функционал, составлялись релизные планы и раз в месяц мы выдавали результат непосредственно заказчику.
Итак, за полгода мы смогли реализовать тот скоуп задач, которые были определены заказчикам. В первую очередь архитектурные, потом функциональные, ну и потом мы дошли до фич, которые, когда бюджет остался, мы смогли реализовать.
Подошли очень гибко к еженедельной отчетности с заказчиком, к ежемесячному контролю трудозатраты бюджета как внутри, непосредственно в нашей команде как исполнителя, а контроль со стороны заказчиков также осуществлялся на ежемесячной основе.
Отчет по заявке, который в принципе осуществлялся каждый месяц, также предоставляли все отчетные документы, которые предусмотрены в рамках 223-го закона. Но он более гибкий, нежели 44-й ФЗ, и поэтому нам удалось реализовать все подходы и ту единую цифровую платформу, которую создали в УК «Роснано».
Михаил Иванов: Мы с вами точно знаем, что эта бирюза к нам пришла не потому, что она должна была прийти, а пришла потому, что мы не можем управлять своими разработчиками в традиционном красном режиме жесткого проектного управления, который был в ходу, когда я был молод. И когда меня вообще никто не спрашивал: «Что ты не успел? А что такое выгорание? И почему 9% выгоревших это лучше, чем 90?». Тогда было всем все равно. Мы с вами все здесь приложили руку к тому, что разложили индустрию. Не потому, что все здесь виноваты, но в среде виноватых мы все есть, включая меня. Поэтому достигать результата необходимого заказчику средствами, которые приемлемы для наших исполнителей, которые, не горят желанием пахать. Потому что, по меткому выражению покойного Вячеслава Сбродова, сейчас в стране модно быть айтишником. И эта мода передалась нам. Мы от этого уходим. Я сразу говорю, каждая теория имеет свои ограничения. Наше ограничение такое, что мы набираем команду возрастную. Мы не работаем в основном с молодежью. Не то, что там прицельно, так складывается. И тут есть еще несколько аспектов, связанных с тем, что команда именно возрастная.
Если я вас каждого спрошу об оценке задачи, которую вы никогда не делали, чем человек опытнее, тем он больше будет привешивать вправо сигм. Потому что опыт – это боль. Опыт никогда не бывает радостью. Опыт всегда боль. И поэтому, чем человек опытнее и, стало быть, профессиональней и экспертнее, тем он больше вам приделывает сигм вправо. И оценка будет колоссальной. Если я эту оценку по спринту выкачу своему заказчику, заказчик скажет: «Ты чего?». Но это будет самое мягкое из того, что он скажет. Так не бывает.
Если вы спросите молодых специалистов, которые всегда оптимистично оценивают проект и никогда его в срок не выполняют, обратите внимание, навсегда и никогда. Лабс подводит итоги, кто как обычно оценку делает. По моим наблюдениям все очень просто. Молодые специалисты ставят амбициозные задачи, они любят челлендж, но никогда его не выполняют.
Поэтому у нас, исходя из этого, формируется определенное ожидание по оценке. Я не скажу, что я руководствуюсь железно одним и тем же правилом, а правило такое. Я беру суммарную оценку, ту, которую мне дали профи, реальные профи, мы не профи не держим. Делю ее пополам. Я большой поклонник critical chain method Элайджи Голдратта. К этому минимуму я прибавляю 50% от него и говорю, Алексей Терентьевич, вот он. За весь спринт оптом. Не разбивая по задачам. Мы с Алексеем Терентьевичем очень быстро разобрались в том, что если он мне говорит «Давай по задачам», я говорю «Окей, это будет сразу на 20-25% больше». И любой внятный заказчик на этом останавливается. Говорит, хорошо, если вы выполняете свои задачи, пусть будет так. Потому что у меня формируется буфер не по задачам спринта, у меня формируется буфер по спринту как таковому.
Но, опять же, ограничением системы является то, что мы работаем на лоу-кодной платформе ELMA, которая позволяет ошибаться. Она создана для команд, которые готовы и рады ошибаться. Поэтому мы этим и руководствуемся.
И тут очень интересная штука. Мне очень понравилась цитата из Хокинга о том, что даже Бог живет неопределенностью, а госзаказчик живет константами. И как тут сбалансировать между одними и другими, это большой вопрос. И между константой и неопределенностью живет наш разработчик, в наших случаях бизнес-аналитик и лоукодер, который, неважно, сколько ему лет, живет, будучи зараженным синдромом студента: все делать в последний момент. Работа занимает весь срок, который мы ей предоставили.
Обратите внимание на ограничения. Так, как я дальше буду рассказывать, готовы работать не все. И эти не все, по нашим наблюдениям, две трети, по вашим, может быть, больше. Это, наверное, как-то коррелирует с возрастом. Не буду говорить как, потому что не знаю. Но точно треть, как минимум, будет уходить. Потому что люди не хотят работать, и мы это должны признать. Врать самим себе – это самая худшая из всех форм лжи. Мы все вот закроем глаза, и отказавшись от неуместной здесь политкорректности, мы все понимаем, что люди не хотят работать.
И треть совсем не хочет работать. Остальные не очень хотят работать.
Вот теперь смотрите, что мы делаем. Безусловно, у меня есть бэклог, в котором существует большое количество технических задач, и я понимаю по специализации, на кого они будут расписаны. Но моя задача, как руководителя – сделать так, чтобы специалист не занимался задачами своего спринта, а сделал их как можно раньше, и начал делать задел задач следующих спринтов.
Когда мы формируем коэффициент трудового участия, мы в нем используем то время, не которое стоило эта задача компании, а то время, сколько эта задача заняла в текущем спринте. То есть, если загодя разработчик выполнил ее, она здесь заняла ноль, у него будет наивысший КТУ. Он мой буфер не съел. Он его съел вечерами, как-то переориентировавшись. Это его дело, он человек взрослый, умный и профессиональный. Он справится сам. Наша задача сказать ему, чего мы от него хотим. Люди делают то, что вы от них хотите. Если вы хотите вписаться в бюджет, вы пробуете вписаться в бюджет. Я не хочу вписаться в бюджет. Я обладаю единоличным правом принять решение, что мы делаем проект в убыток. Я хочу, чтобы все было сделано так, как надо, и заказчик был доволен. И не просто так. Безусловно, мне радостно видеть, когда заказчик говорит: «О, ProActor – круто». Но мне еще, как владельцу компании, важно понимать, что это будет следующая продажа с меньшими затратами на реализацию. То есть тут, поверьте, не безосновательная щедрость. Эта щедрость имеет свои результаты. И команда мотивируется так достаточно хорошо, очень быстро, за 1-2 проекта люди к этому привыкают.
Тут еще надо понимать, что один из наших лайфхаков говорит, что мы на сотрудника не планируем больше 75% его теоретической загрузки. Вообще. Никогда. Начиная со второго спринта и до предпоследнего, ключевые сотрудники, а их приблизительно около половины команды, работают только на этом проекте. А остальные привлекаются к проекту по спринтам, но каждый спринт, каждый человек участвует в одном проекте. Оставьте иллюзию, что разработчики, аналитики, системные аналитики могут работать над некоторыми задачами параллельно. Скорее нет, чем да. Понятно, что есть набор исключений, лишь подтверждающие правила, но не любят так люди делать. DevOps-инженеров мы, как самых дорогих, привлекаем всегда по необходимости.
Я этоиз реальных проектов взял, анимизировав данные. Понятно, что из бэктрекинговой системы. Я вам демонстрирую реальные цифры, насколько это эффективно. Чем больше у нас спринтов… то есть 20 спринтов, это вообще удобно. Это означает, что я все инфраструктурные задачи закрою к 10-му, 12-му и высвобожу самый дорогой ресурс, разработчиков, на следующие проекты. То есть, я в единицу проектов могу делать чуть больше, чем мои конкуренты. И вот это является конкурентным преимуществом, которым легко делиться, потому что его сложно реализовать.
