Привет, Хабр! Меня зовут Анзор Кардан, я руководитель продукта Teamplanner в Х5 Tech. В статье я поделюсь собственным опытом выбора инструмента планирования проектов, через какие стадии мы прошли и с какими сложностями столкнулись (спойлер: в итоге мы разработали свой собственный инструмент). Как и в любой другой крупной компании, в Х5 Tech идёт непрерывная генерация новых IT-проектов, постоянный поиск направлений, за счёт которых можно повысить эффективность бизнеса, а также удержать технологическое лидерство. Ежегодно мы оцениваем свыше 700 таких инвестиционных инициатив.  Таким образом, мы столкнулись с определённым вызовом: с помощью какого инструмента мы сможем получить ответы на эти вопросы? И не менее важная задача: как потом обеспечивать непрерывный процесс планирования проектов и ресурсов, при том, что компания постоянно меняется и проходит через различные трансформации?  Дальше об этом пойдёт речь. Давайте посмотрим, какие существуют варианты выбора инструмента планирования проектов в компаниях. Основываясь на моём личном опыте, я вижу примерно такую картину: Большинство компаний начинают с методики «пол-палец-потолок», и для некоторых этот инструмент планирования более чем достаточен. В основном это небольшие компании или стартапы, где количество проектов раз-два и обчёлся, им даже в Excel нечего сводить – информация по проектам хранится «в голове» участников. Этот вариант мы не рассматриваем. Дальше идёт классическое использование Excel (вариант 1), то есть в нём ведётся всё! Это некий «золотой стандарт», от которого многие компании и по сей день не могут отказаться. Большинство же средних и крупных компаний используют JIRA или другой таск-трекер, а некоторые до сих пор живут с Project-сервером (вариант 2). Но учитывая текущую геополитическую обстановку и уход с российского рынка крупных вендоров, возникает дилемма: а на какой инструмент дальше переходить?  В ответах на этот вопрос многие начинают плавно уходить в бесконечное турне по поиску решений, где проводят анализ существующих SaaS и On-premise систем (вариант 3), общаются с большим количеством поставщиков решений и вендоров. По моему опыту и по общению с коллегами по цеху, в итоге внутренние подразделения не могут друг с другом договориться и выбрать единое решение – всё равно остаются внутренние особенности и бизнес-процессы, которые не покрываются предлагаемыми решениями, и всё равно требуются дорогостоящие доработки.  Когда «богатые» компании не могут выбрать поставщика, многие из них обращаются к крупным консалтинговым компаниям (вариант 4) в попытке найти лучшие решения и получить полноценную консультацию. Как правило, после обращения к «богам» компании получают классные и сочные презентации, суперметодики и потрясающее шоу с расчётами и покрытием запрашиваемого функционала. И, как следствие, довольных директоров.   Но после того, как заканчивается «шоу» и начинается реальная жизнь, попытки разработки или внедрение по методичке – то есть всё, что описано в красивых презентациях – превращается в тыкву, становится невыносимо дорого всё это внедрять и поддерживать. И тогда наступает жуткое «похмелье» и ощущение бессилия от осознания того, что можно действительно внедрить классную систему планирования и поддерживать существующие разношёрстные бизнес-процессы.   В конце концов финальным этапом является принятие решения о собственной разработке инструмента со всеми его плюсами и недостатками (вариант 5).  До моего прихода в Х5 Tech планирование в компании происходило в основном в Excel (вариант 1), условно был и Project-сервер, была (и есть пока что) JIRA с набором плагинов (вариант 2). Также была активность по внедрению нового типа ИСУП на базе Sharepoint, но выбранный стек и решение явно проигрывали современным SaaS-сервисам по функциональности и UI/UX, поэтому я понимал, что это решение нам не подойдет. Технический прогресс шёл вперёд, появлялись новые задачи и требования от бизнеса, но в варианте 2 нельзя было ничего сделать дополнительно, например, внедрить дополнительные фичи, поменять флоу, добавить «немного души» в интерфейсе планирования и управления инициативами. Любая доработка процесса и инструмента выливалась в большой проект со своей экономикой, написаний БТ/ТЗ архитектурных схем и т. д.  В какой-то момент компания начала двигаться в сторону варианта 3. Даже пригласила нескольких вендоров для оценки применимости их решений в наших условиях. Но в итоге после нескольких демо и эта активность была припаркована… Ко мне попала задача под кодовым названием «гибкие штатки», по ней практически не было никаких материалов, только видеозапись совещания на 500 мб. То есть, по сути, нужно было всё придумать с нуля.  Мы вместе с Женей (системный аналитик команды) начали штурмить над задачей, опрашивали старожилов о том, как у них устроено планирование команд, какие есть процессы и системы, что не устраивало и т. д. Но все ответы были достаточно общими: «сейчас непонятно и неудобно, хочу, чтобы было понятно и удобно». Мы провели более 30 интервью, поговорили с сотрудниками разных уровней и ролей (административные руководители, владельцы продуктов, руководители проектов, менеджеры C&B, ресурс-менеджеры, директора). Мы обклеили кабинет директора стикерами с сущностями, ломали голову над тем, какая сущность первичнее – «команда» или «проект», «сотрудник» – это сущность проекта или команды?   Так мы начали нашу историю.  Найти свободного дизайнера внутри компании оказалось проблематично, поэтому я решил не тратить время и сам собрал в FIGMA кликабельный макет, который я носил на совещания и показывал всем подряд, собирая обратную связь. Скажу честно, что мы столкнулись с колоссальным объёмом задач уже на старте. И если бы в начале пути мы знали, с чем нам придётся иметь дело, то, наверное, и не начинали бы вовсе :) Помогло только одно – девиз «Слабоумие и отвага»! Помню первое совещание, где я представлял первые наброски и идеи продукта, и получил порцию обратной связи из серии: «А это вообще заработает?». Дальше – больше. После получения финансирования и чем дальше мы копали эту историю, мы всё больше и больше удивлялись количеству задач, о которых речь пойдёт ниже.  Первое, с чем мы столкнулись – это наличие аналогичных конкурентных продуктов в периметре Х5 Group. Разные команды под разным углом решали задачи своих подразделений. Поэтому необходимо было чётко сформулировать отличия нашего инструмента от классических систем планирования, и сделать его «другим».  После нескольких встреч и демонстрации нашего решения мы столкнулись с сопротивлением консервативной публики и почувствовали недоверие к такого рода активностям. Старожилы говорили нам, что схожие активности и попытки уже имели место быть, поэтому ничего хорошего у нас не выйдет.  Учитывая, что мы работаем в крупной компании, где IT-ландшафт строился годами, даже десятилетиями, то ряд трудностей был связан также с получением данных и построением витрин, в которых была бы собрана вся необходимая информация для разработки новых бизнес-процессов. Некоторые данные и поля мы ждали по 9–10 месяцев.  Следующим вызовом для нас стало отсутствие актуальной или согласованной методологии между всеми подразделениями в части планирования инициатив. И так как строились новые процессы и инструмент развивался, то приходилось эту методологию по ходу прорабатывать и добывать нужные нам сведения. Где-то мы экспериментировали и пробовали, очень много ошибались, потом переделывали.  Также после получения более-менее работающей версии отдельным челленджем для нас было обучить сотрудников. За неделю коллеги из нашей дирекции вместе с нами обучили работе с системой 1 600 сотрудников. На вопросы пользователей приходилось отвечать днём и даже ночью без перерыва и выходных. Конечно же, мы сталкивались с недовольством пользователей, т. к. раньше было удобно (точнее, привычно), а теперь непонятно. Мы проводили демо, даже если на встречу приходил один пользователь. Но всё это мы пережили. Мы назвали наш собственный инструмент планирования – Teamplanner.  Мы решили задачу непрерывного планирования проектов в компании и теперь получаем широкую картину занятости сотрудников X5 Tech.  Пройдя долгий путь в полтора года, сейчас мы видим результаты нашей работы – системой планирования пользуются, все данные вносятся, вся отчётность выгружается, большинство сотрудников довольны. Основываясь на своём личном опыте, приведу ниже несколько советов тем, кто собирается внедрить или создать подобный инструмент в своей компании:     Проанализируйте аналогичные решения: наиболее подробно изучите SaaS и on-premise решения, которые уже существуют на рынке, прежде чем начать собственную разработку. Становитесь мастер-системой: постарайтесь, чтобы процесс заведения сущности начинался у вас, и становитесь мастер-системой т.к. любая интеграция для получения данных это неизбежные страдания. Управление нормативно-справочной информацией: пусть методологи становятся источником изменений справочных данных, особенно если в вашей компании много продуктов используют одни и те же данные. Относитесь к негативу спокойно: приготовьтесь к тому, что пользователи продукта будут хейтить вас в начале пути - это нормально. Важно выстроить грамотную пользовательскую поддержку, быстро отвечать на вопросы пользователей и решать их проблемы. Буду рад, если поделитесь в комментариях вашим опытом разработки и внедрения подобной системы планирования. И, конечно же, с удовольствием отвечу на вопросы.        Руководитель продукта Teamplanner X5 Tech