Ни точное определение целей, ни правильный выбор типа проекта не устранят фундаментальный источник неопределенности – человеческий фактор. Все зависит от решений людей, участвующих в проекте и создающих цифровые продукты. Как я уже писал, природа технологических проектов кардинально отличается от классических отраслей. На производстве корректно запрограммированное оборудование или настроенный процесс гарантированно приводят к ожидаемому результату, а в проектной работе все зависит от способностей людей. Результаты проекта – плод их творческой фантазии. Специалисты, занимающиеся проектированием, дизайном, разработкой, работают с чистой мыслью, а их инструменты, такие как среды разработки или графические редакторы, – лишь способ выразить свои идеи. В любой задаче есть вариативность, и по большому счету не существует алгоритма для поиска «правильных» решений. Способность принимать решения, которые дадут нужный результат, определяется качествами конкретного специалиста, его опытом, знаниями, профессиональным подходом и способом мышления.
Однако бизнес при запуске проектов и выборе специалистов ориентируется на количественные параметры: сроки, бюджет, количество людей с определенными компетенциями. При этом упускаются не менее важные, просто не столь понятные, качественные характеристики кандидатов для реализации их проектов. Имея в виду кандидатов, я говорю не только о конкретных людях, но и о командах в целом как о единых проектных организмах. И люди, и команды обладают уникальными личными и профессиональными качествами, которые тоже нужно учитывать, а после запуска проекта уметь использовать эти качества для достижения результата. Такое умение – это тоже компетенция. Ее отсутствие со стороны бизнеса делает процесс работы над проектом непредсказуемым.
Даже один специалист способен сорвать работу всей команды, если от его результатов зависят остальные участники. Достаточно затянуть выполнение задачи или принять решения, которые в дальнейшем скажутся на всех частях будущего продукта. Например, неверный выбор технологии хранения данных может привести к тому, что сайт интернет-магазина не выдержит большой нагрузки. Это повлечет за собой серьезную переработку всех частей сервиса, потребует дополнительного времени и денег, и могут образоваться новые проблемы. Если ошибку допустит архитектор системы, ее цена может стать еще выше, а выяснится это, возможно, когда уже будет поздно что-то менять.
Удивительно, как часто компании игнорируют здравый смысл и выбирают исполнителей исключительно по формальным признакам. При выборе не проводится личных встреч, пока не определится победитель конкурса. В ряде случаев личный контакт и создание хороших дружеских отношений между сторонами проекта считается вредным, ведь может негативно повлиять на установленные в компании процедуры. Сказать, что это глупость, означало бы не придать проблеме большого значения. Такой подход наносит будущему проекту урон в его основании, потому что игнорирует суть проектной работы.
Иногда ситуацию спасает наличие необходимой компетенции со стороны компании, которая предоставляет услуги по созданию цифровых продуктов. Но чтобы проект не был лотереей, бизнес должен понимать критерии и подходы для выбора подходящих специалистов. В противном случае он становится заложником целей компании-поставщика. В зависимости от бизнес-модели такая компания склонна предлагать выгодные для нее условия. Например, постарается продать как можно больше часов своих специалистов или предложит продукт или технологию, формируя проектную команду в соответствии с типовой схемой внедрения. Все это может принести нужный результат, но только если соответствует изначальным целям бизнеса.
Идеально, когда на стороне бизнеса есть люди, которые понимают задачи проекта и разбираются в IT-индустрии. Конечно, такие навыки и опыт – большая редкость, поэтому бизнес идет более простым путем и делегирует поиск тех, кто сможет реализовать проект, в отдел закупок или тендерный комитет.
Тендерные процедуры
Несколько лет назад мы с Дмитрием «Goblin» Пучковым записали ролик о тендере Почты России на разработку мобильных приложений. Мы подробно разобрали не только конкретную историю, но и общую ситуацию с процедурой заказа программного обеспечения в коммерческих и государственных компаниях. Прошло много времени, но ситуация не изменилась. Это было бы простительно 20–30 лет назад, когда создание цифровых продуктов для бизнеса только начиналось. Теперь, когда слово «цифровизация» уже неприлично произносить, это выглядит странно.
Оставим в стороне вопросы коррупции, при которой бессмысленно искать здравый смысл в происходящем. В подобных ситуациях цели организаторов тендеров отличаются от целей бизнеса и часто им противоположны. Но даже если взять вариант с добросовестными намерениями, то, по сути, правила выбора поставщика для работы над проектом все еще не сильно отличаются от закупки мебели или поставки оборудования, что совершенно точно не идет на пользу ни бизнесу, ни проектной команде.
Как и в случае обычного заказа, бизнес формулирует требования к будущему продукту или сервису. Потенциальные исполнители готовят свои предложения на основе этих требований. Выбор делается с учетом предложенных сроков, стоимости и уровня доверия к поставщику. То, что на данном этапе подобные оценки носят условный характер, остается за скобками. Этот подход напоминает спиритический сеанс или гадание, несмотря на внешнюю солидность.
Бизнес таким образом стремится уменьшить неопределенность, считая, что контракт с заранее согласованными условиями служит гарантией получения нужного результата. Такой метод вступает в противоречие с природой проектной работы и фактически еще больше увеличивает неопределенность, и, кроме того, создает непомерные трудности на пути к цели проекта. Дело в том, что цифровой продукт, как я описал в первой главе, работает в симбиозе с бизнесом. Без знания технологических возможностей компания не сможет сформулировать требования к продукту. Это уравнение с несколькими переменными, где с одной стороны бизнес-модель, с другой – технологические инструменты. Делать одно в отрыве от другого бессмысленно. Поэтому когда бизнес не вовлекает IT-специалистов в процесс формулирования требований в формате отдельного проекта, то рискует получить результат, которым не сможет воспользоваться.
Такой подход ограничивает не только бизнес, но и компании, претендующие на заказ. У них мало исходных данных для подготовки предложения и короткие сроки для принятия проектных решений, на основе которых можно было бы оценить будущий проект. На качество этой работы влияет и факт, что она не оплачивается, а на вход в компанию поступает поток запросов на проекты, и нет ясности, какой из них будет выбран. В результате самые важные для проекта решения принимаются в наименее подходящий для этого момент, и, очевидно, они будут не самыми удачными.
Даже если по ходу проекта появятся новые вводные и более удачные способы реализации продукта или решения бизнес-задач, пересмотреть первоначальные решения не получится. Дело в том, что на них построена оценка, которой поставщик должен придерживаться в рамках изначальных договоренностей. Так, пытаясь устранить неопределенность и гарантировать выполнение проекта, бизнес, наоборот, лишает команду возможности сделать его лучше.
Теперь вернемся к основной теме – людям, которые работают над проектом. Выбор специалистов должен определяться объективными потребностями, вытекающими из целей и типа проекта, а также технологическими особенностями создаваемого продукта. На практике это становится ясно далеко не сразу. Формат процедуры выбора подрядчика требует определиться с требованиями к составу проектной команды в самом начале, когда происходит оценка. От количества специалистов, компетенций и профессионального уровня зависит стоимость работ и принципиальная возможность подобрать подходящих кандидатов к началу проекта. В результате судьбу проекта определяют не только преждевременные технические решения, но и люди, выбранные на ранней стадии. Каждый из них может быть отличным профессионалом, но не подходить для решения задач конкретного проекта. Универсальных специалистов не существует.
Критерии выбора исполнителей для управления неопределенностью
Какими же критериями тогда должен руководствоваться бизнес при выборе специалистов для проекта? Прежде всего необходимо перестать считать всех работников IT-отрасли «программистами». Это все равно что считать всех, кто занимается строительством «строителями». Также необходимо отказаться от мысли, что «программисты» отличаются друг от друга «сообразительностью» и при достаточном уровне способны решить любые задачи. И, наконец, не стоит рассчитывать, что «программистам» можно поставить задачу, просто «объяснив на пальцах». Но об этом мы поговорим позже.
Если перевести этот список для чайников на более профессиональный язык, то можно сказать, что для разных типов проектов процедура выбора исполнителей должна отличаться, и отличия будут носить принципиальный характер. В одних случаях специалисты подбираются под проект, а в других сам проект зависит от привлеченных профессионалов.
Вернемся к рассказу о неопределенности в разных типах проектов. Теперь, когда мы переключились на людей, можно прямо сказать, что они и есть источник неопределенности. Уровень неопределенности разных типов проектов определяется ролью участников проектных команд. Один и тот же человек, работая над разными проектами, по-разному влияет на предсказуемость результата. Его личные и профессиональные качества могут быть полезны для одного типа проектов, и мешать в другом.
Для себя я сформулировал правило: уровень креативности специалиста обратно пропорционален его ответственности и наоборот. Проще говоря, чем более неординарно и с неожиданной стороны человек решает задачи, тем меньше можно на него положиться. Это связано с тем, что творческий подход доступен тем, у кого нет психологических ограничений и сковывающих обязательств. Внутренняя свобода распространяется на отношение человека к внешним правилам, а традиционные способы мотивации не работают с такими людьми.