Содержание
  1. Бизнес-процесс
  2. Основные проблемы на проекте
  3. Результаты комплексной работы
  4. Формат проведения консалтинга
  5. Подходы и решения
  6. Этапы работы
  7. Стратегия консультирования
  8. Достижения
    компании-заказчика
  9. Отзыв заказчика

Консультирование по выходу из технологического кризиса
и улучшению психологической атмосферы
в компании, разрабатывающей высокотехнологичное ПО

Срок реализации проекта: 1,5 года
Смотреть другие кейсы

Бизнес-вызовы

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

Контекст сотрудничества

В начале жизненного цикла проекта у владельца компании было неформальное общение с Дмитрием по техническим нюансам и дальнейшему развитию продукта. Изначально, в 2013 году, Дмитрий транслировал точку зрения о необходимости применения подхода Data Driven Testing. Также советовал организовать процесс поставки через CI/CD. Однако в тот момент заказчик отдал предпочтение быстрому росту компании, а не постепенному внедрению инженерных практик, приносящих ценность в долгосрочной перспективе. Команда разработки фокусировалась на оперативном наращивании функционала и выходе продукта на рынок. Выбранный подход имел эффект: компания действительно достаточно быстро выросла, но уже через 4 года владелец продукта увидел проблемы со стабильностью, поставками и немасштабируемостью системы. Он вспомнил рекомендации Дмитрия и в 2019 году решил обратиться к нему за помощью.

Ситуация на проекте

К моменту, когда владелец компании обратился за консультированием к Дмитрию, проект уже достиг значительных успехов. Небольшой стартап вырос в полноценный успешный бизнес с устойчивыми продажами. Клиентам компании стали с клиентами крупнейшие корпорации в РФ. Однако дальнейшее его развитие было труднореализуемым: с технической точки зрения продукт стало сложно модернизировать. Релизы системы были крайне нестабильным, поставки стали нерегулярными. Также были серьёзные проблемы, связанные с внедрением новых сотрудников в команду, увеличился BUS-фактор (критическая зависимость от конкретных сотрудников). Кроме того, в команде отслеживались проблемы с культурой, коммуникациями и организацией процессов. К такой ситуации на проекте привели несколько причин:

  1. Технологические сложности продукта. Изначально проект развивался как стартап, поэтому в процессе его разработки не были применены многие важные практики и подходы. Соответственно, не были внедрены принципы непрерывной интеграции и поставки (CI/CD). Написание Unit-тестов было редкой практикой и применялось ситуативно: покрытие кода составляло около 10%, при внесении любых изменений в код возникало большое количество багов. Также не было и автоматизированного UI-тестирования, так как его внедрение было ещё более сложной и трудозатратной задачей, требующей применения отдельного фреймворка. Ручное тестирование осуществлялось несистемно, регрессионное тестирование не проводилось. Тест-менеджмент не был организован, вследствие чего не выстроены необходимые процессы по контролю качества.
    Система сильно усложнилась по причине накопления большого количества исходного кода разных версий, написанных разными поколениями сотрудников. Инженеры, работающие над продуктом, использовали разные подходы к культуре кодирования, не соблюдался принцип преемственности в архитектуре.
    Таким образом, продукт достиг критической точки накопления технических долгов, когда было невозможно его дальнейшее развитие. Крепкие взаимосвязи между техническими долгами не позволяли команде самостоятельно работать над одним из них, не затронув другие. Прежде чем реализовывать процесс непрерывной интеграции и поставки, было необходимо провести рефакторинг системы. Однако успешность рефакторинга было невозможно объективно оценить при отсутствии Unit-тестов, поэтому попытки провести рефакторинг проходили болезненно и сложно. Без навыков и опыта рефакторинга у команды не развивалось стратегическое мышление, в результате чего инженеры не могли системно работать над улучшением архитектуры. Помимо этого, проработка архитектуры была сложно реализуема без автоматизированного контроля над стабильностью: любые изменения могли привести к новым багам.  В такой ситуации даже поддержка продукта обходилась очень дорого и требовала значительных трудозатрат.
  2. Невыстроенные процессы. На проекте не поставлен процесс бизнес-анализа. Сбор требований у заказчиков продукта осуществлялся нерегулярно. Требования поступали команде в форме пожеланий и в таком же виде попадали в систему трекинга (Jira), но уже в качестве задач для разработчиков. Таким образом, задачи не имели критериев выполнения и описания того, как желаемый функционал должен выглядеть и работать.
    На проекте не была налажена практика постановки задач на итерацию. Работа над ними происходила несистемно, в процессе постоянно добавлялись новые требования, менялись приоритеты. Дедлайны определялись на основе предположений команды разработки.
    Отсутствие планирования и систематизированной работы над задачами в сочетании с большим количеством багов при любых изменениях стали причиной проблем с поставками. В результате релизы осуществлялись раз в год, с задержками до 4 месяцев.
  3. Проблемы с коммуникациями, высокая токсичность в команде. С психологической точки зрения у владельца бизнеса и разработчиков установились рассинхронизация и недопонимание. В команде не было инженера, который смог бы обратить внимание владельца на необходимость работы с технически долгом. А сам владелец тогда ещё не считал нужным инвестировать в работу с техническими долгами. Постоянное недовольство инженеров и негативная обратная связь от владельца привели к тому, что в команде накалилась атмосфера и увеличилась токсичность.
  4. Выученная беспомощность. Инженеры не видели возможности развивать продукт дальше в таких условиях. Встретившись с очередными сложностями в процессе изменения и расширения кода, они опускали руки и даже не пытались преодолеть очередные препятствия.

Основные проблемы на проекте

  1. Низкая производительность команды разработки из-за огромного объёма (более 400 000 строк) высокосвязанного legacy-кода, не поддающегося изменениям.
  2. Отсутствие мануального и автоматизированного тестирования и, как следствие, регулярные сбои поставок и непредсказуемо возникающие баги в продукте.
  3. Плохо поставленные процессы (процессы планирования разработки, бизнес-анализа, тестирования, поставки ПО, административные процессы).
  4. Токсичная атмосфера в команде / недопонимание между владельцем продукта и командой.
  5. Выученная беспомощность у инженеров.

Результаты комплексной работы

с 8% до 22%
с 8% до 22%
увеличилось покрытие кода Unit-тестами
в 3 раза быстрее
в 3 раза быстрее
новые сотрудники погружаются в проект
в 2 раза
в 2 раза
ускорился выпуск новых версий продукта и возросло количество созданного к релизу функционала
более, чем в 15 раз
более, чем в 15 раз
уменьшилось время, затрачиваемое специалистом за сборку 1-й лицензии

Отзыв о результатах комплекной работы

Формат проведения консалтинга

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

Дорожная карта консультирования
  1. Дмитрий консультирует владельца компании в формате личного общения.
  2. Дмитрий и менеджер проекта погружаются в компанию, анализируют ситуацию, составляют видение по основным процессам и согласуют его с СЕО и СТО компании-заказчика.
  3. Дмитрий и менеджер проекта проводят первые две итерации изменений, по результатам каждой из них проводится общая ретроспектива. Выполняется анализ результатов.
  4. На проекте остаётся менеджер, который продолжает внедрение всех процессов. Каждые 2 месяца Дмитрий подключается к проекту, проводит оценку результатов и формирует дальнейшую стратегию улучшений.
  5. Проводится финальное демо проведённых улучшений с заказчиком, подводятся итоги сотрудничества.

Подходы и решения

Зная о репутации Дмитрия и его успешном опыте развития собственной компании, владелец продукта полностью доверял ему. Соответственно, со стороны руководства был дан «зелёный свет» на любые изменения, что положительно повлияло на успешность и высокую скорость достижения результатов консультирования. Начав с личного общения с заказчиком, Дмитрий развивал работу с компанией в нескольких направлениях.

Направления работы
  1. Установление прозрачности всех коммуникаций на проекте
  2. Работа с техническими долгами (в том числе, постановка технических процессов: CI/CD, Unit- и Ui-тестирования, архитектурного планирования)
  3. Постановка процессов управления проектом, тестирования и бизнес-анализа
  4. Работа с культурой и ценностями команды

Этапы работы

  1. 1 этап:
    Личное консультирование владельца компании

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

  2. 2 этап:
    Коммуникации

    Когда Дмитрий пришёл в компанию и познакомился с командой разработки, он увидел, что на проекте работают хорошие специалисты, которые делают отличный продукт. Проблема была в том, что они смотрели в неправильном направлении: не фокусировались на стратегическом планировании, не придерживались инженерной культуры и не были готовы услышать друг друга. Поэтому прежде чем приступать к технологическому улучшению продукта, необходимо было наладить коммуникационные процессы и взаимоотношения между командой и владельцем компании.
    На проекте начали проводиться мероприятия Scrum-методологии: введена практика ежедневных стендапов, на регулярной основе начали проводиться демо новых версий продукта. Также были внедрены ретроспективы, которые способствовали самоорганизации команды.
    Теперь каждый участник проекта понимал, что его мнение будет принято и учтено. Владелец прислушивался к членам команды, а команда — к его словам.
    Фаза оптимизации коммуникаций заняла несколько месяцев. Постепенное внедрение мероприятий Scrum-методологии (ретроспектив, стендапов, демо) позволило достичь первых результатов. По словам заказчика, за первые три месяца со старта консультирования команда разработала столько же нового функционала, сколько ранее разрабатывала за год. С точки зрения управления процессами ситуация на проекте стала более прозрачной и прогнозируемой. Собственник начал понимать, какие проблемы и недовольства есть у команды разработки и в чём их причины. Также он смог убедиться в том, что Дмитрий бережно относится к его бизнесу и увидел, что преобразования могут быть постепенными и с низкими рисками, несмотря на всю сложность ситуации.

  3. 3 этап:
    Технические долги

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

    1. Внедрение автоматизированного тестирования (Unit-, UI- и интеграционного тестирования).
    2. Внедрение непрерывной интеграции и поставки (CI/CD).
    3. Рефакторинг legacy-кода.
    4. Улучшение архитектуры продукта.

    Так как система имела сложную архитектуру и нетипичный стек технологий, задача по внедрению CI/CD и автоматизации тестирования была действительно нетривиальной и требующей исследований. Продукт представлял собой десктопное решение с установленной аппаратно-программной защитой, а также защиту через удалённые сервера. При запуске автотестов напрямую постоянно требовалось наличие USB-ключа защиты, поэтому было необходимо найти и применить подходящий фреймворк UI-автотестирования. Осложняло ситуацию и то, что ранее инженеры не имели опыта работы с UI-автотестами. В команде установилось высокое сопротивление к их написанию: у сотрудников не было мотивации работать над сложной, абсолютно новой для них задачей. Поэтому было принято решение начать ежедневные исследования (1 час в день) по автоматизации тестирования и внедрению CI/CD и постоянно отслеживать прогресс. Такой подход постепенно приучил инженеров к работе с техническими долгами и позволил более эффективно проводить исследование: не зацикливаясь на одной задаче, решение удавалось находить быстрее. Кроме того, теперь инженеры не могли отказаться от работы по техническому долгу под предлогом наличия более приоритетных задач.

    Спустя несколько месяца с начала работы над техническими долгами удалось добиться значительных улучшений. Для автоматизированного UI-тестирования критических функций продукта был успешно применён выбранный по результатам исследования фреймворк. Инженеры начали регулярно писать UI и Unit-тесты. В Unit-тестировании использован подход Data Driven Testing, упрощающий ввод входных данных, что особенно важно для системы с большим количеством расчетных модулей.

    Несмотря на высокое сопротивление команды, были внедрены непрерывная интеграция и поставка (CI/CD). Спустя 2 месяца данная практика начала приносить первые результаты: процесс создания дистрибутивов продукта стал быстрым и безопасным, что позволило существенно высвободить время и увеличить производительность команды. Постоянная работа с техническим долгом стала неотъемлемой частью спринтовых задач.

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

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

  4. 4 этап:
    Постановка процессов

    Параллельно с работой над техническим долгом был внедрён профессиональный тест-менеджмент. Под руководством выделенного проектного менеджера со стороны команды консалтинга выстроены процессы и созданы тест-планы для мануального и автоматизированного тестирования, что позволило более профессионально управлять качеством продукта.
    Также было необходимо оптимизировать процессы сбора требований, формирования и постановки задач. На основании собранных командой пожеланий заказчиков создана система обработки задач (workflow). Далее был скорректирован процесс обработки требований и преобразования их в задачи. Предметная область, в которой применялся продукт, отличалась особой сложностью. Преобразование требований в конкретные задачи было действительно трудоёмким процессом, который нуждался в дополнительных исследованиях, подборе научных статей. Иногда возникала необходимость в разработке модели, на основе которой формировалось техническое задание для инженеров. Для реализации стратегии команда была пополнена новыми бизнес-аналитиками с бэкграундом в научной сфере. Также было выделено время для дополнительных научных изысканий. Такой подход позволил формировать требования более конкретно и точно. Теперь задачи для команды разработки имели критерии выполнения (Definition of Done), инженеры смогли самостоятельно проводить их декомпозицию и эстимирование.
    Кроме того, была выстроена система оценки рисков. При уточнении требований по конкретному функционалу бизнес-аналитик оценивал, возможна ли в принципе поломка критически важных частей продукта. Если такая возможность присутствовала, он инициировал проведение отдельного митинга, на котором обсуждались мероприятия по обработке рисков.
    Далее были приняты меры по улучшению процесса поставки. Дмитрий ввел на проекте практику регулярного планирования спринтов (отдельные митинги), груминга бэклога. В команде начал проводиться предварительный анализ, определяющий следующий срок релиза. Если ранее специалисты из-за больших неопределенностей в разработке фокусировалась на отдельных задачах, то после введения практик планирования команда была нацелена реализовать весь намеченный набор функциональностей к релизу. Эффективные подходы к планированию и внедрённые инженерные практики (CI/CD, автоматизация тестирования) положительно сказались на процессе поставки продукта: команда смогла осуществлять релизы в запланированный срок. А количество релизов за год увеличилось в два раза. При этом дальнейшее увеличение частоты уже не имело смысла, так как заказчики не были готовы обновлять ПО с более частой периодичностью.

  5. 5 этап:
    Изменение культуры и преодоление выученной беспомощности команды

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

    1. опозданий на стендапы;
    2. готовности к стендапу;
    3. прогресса по написанию Unit- и UI-тестов;
    4. прогресса по внедрению CI/CD;
    5. ежедневное состояние отработанных за ночь тестов;
    6. уделяемого разработчиками времени на работу с техническим долгом;
    7. достижения целей спринта.

    Цель данных инструментов — зафиксировать малейшие шаги и улучшения, чтобы команда постоянно видела прогресс. Средства визуализации наглядно показывали специалистам, в каких моментах на проекте есть проблемы, над чем необходимо работать и какие процессы должны постоянно отслеживаться. Кроме того, это способствовало контролю над соблюдением установленных правил и практик. Например, график учёта времени, затраченного на работу с техническими долгами, способствовал установлению практики постоянного написанию автотестов инженерами.
    Еще один инструмент влияния, который позволил повысить культуру в команде разработки — написание документации инженерами. Смысл такой практики заключается в улучшении качества работы специалистов. Когда инженер понимал, что должен написать понятный мануал по использованию к созданной утилите, он подходил к процессу разработки более вдумчиво. Это должен был быть законченный функционал, работу которого можно изобразить несложной диаграммой и понятной последовательностью действий.
    Для повышения результативности различных встреч и обсуждений у каждого инженера появилась рабочая тетрадь, в которой он должен был помечать поставленные перед ним задачи, чтобы потом самостоятельно занести их на Scrum-доску. Так все обсуждения не проходили впустую, полученные задачи и вопросы не забывались и всегда обрабатывались. Кроме того, это позволяло отследить контекст обсуждений в спорных ситуациях.
    Еженедельно разработчики демонстрировали результаты проделанной за неделю работы, отвечали на вопросы, получали пожелания и замечания от команды (командное демо). После такого мероприятия каждый участник проекта понимал, как функционируют определенные части продукта. С другой стороны, каждый инженер мог поделиться удачными решениями, применёнными в процессе работы над задачей.
    С появлением первых успехов команда постепенно получила веру в то, что выбраться из сложной ситуации на проекте вполне реально. Это способствовало преодолению выученной беспомощности. Инженеры начали искать пути решения проблем, а не причины, почему их невозможно решить, наконец увидели результаты своей работы и осознали, что сдвинулись с мертвой точки. Атмосфера в команде стала более доброжелательной: наладились коммуникации, владелец стал с командой на одну сторону. Увеличилась мотивация к накоплению лучших практик и появилось понимание, что усилия каждого человека действительно делают продукт лучше.

Стратегия консультирования

Работая над данным проектом, Дмитрий применил весь свой обширный опыт: использовал навыки архитектора, менеджера и СЕО собственной IT-компании. Эта триада дала возможность эффективно видоизменить культуру компании-заказчика.

Технологическая сторона и архитектура продукта

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

Управление административными процессами и установление культуры компании

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

Постановка процессов разработки

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

Начав изменения с оптимизации коммуникаций и технологического ядра продукта (в центре которого был CI/CD и Unit-тесты), Дмитрию удалось распространить влияние ценностной культуры практически на все стороны жизни компании: бизнес-анализ, административное управление и развитие бизнеса. Таким образом, заказчик получил не просто технологический или процессный консалтинг. В конечном итоге улучшения коснулись всех сторон жизни компании.
Благодаря полному доверию клиента к Дмитрию была достигнута высокая скорость внедрения улучшений. Компанию с несовершенными процессами и непрозрачным управлением за 1,5 года удалось преобразовать в инженерную компанию с современной культурой и ценностями, что стало плацдармом для дальнейшей масштабизации и роста продукта. Система получила новый толчок для развития. При этом удалось сохранить ключевых участников команды, несмотря на масштаб изменений и колоссальные перемены в ежедневной работе и мировоззрении, через которые прошёл каждый сотрудник.

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

  1. Владелец компании осознал необходимость постоянной работы с техническим долгом, пришёл к решению инвестировать в CI/CD и стал постоянным драйвером создания новых автоматизированных UI-тестов. За полтора года покрытие кода Unit-тестами увеличилось с 8% до 22%.
  2. Налажена работа по устранению технических долгов:
    • В команде заказчика внедрена практика постоянного написания автотестов (Unit, DDT, UI), что позволило вносить изменения в продукт безопасно и эффективно.
    • Внедрена CI/CD-культура, благодаря чему процесс поставки продукта стал существенно более быстрым и стабильным.
    • Налажена системная работа по рефакторингу и улучшению архитектуры сложной системы.
  3. Организованы процессы:
    • Бизнес-анализа/создания требований к ПО.
    • Оценки рисков.
    • Планирования разработки.
    • Обеспечения качества.
    • Поставки ПО.
  4. В команде сформирован ценностный подход к процессу разработки. До нашего включения в проект главной целью команды было быстрое внедрение функционала, специалисты не задумывались о качестве и поддержке продукта. Уже через 3 месяца со старта сотрудничества команда разработки заказчика начала сокращать технический долг, использовать и накапливать лучшие инженерные практики, вести необходимую документацию, при этом увеличив скорость создания нового функционала.
  5. Улучшен психологический климат в команде, выросла мотивация к преодолению выученной беспомощности. Существенно уменьшена токсичность, установлена здоровая рабочая атмосфера на проекте, налажены коммуникации и взаимоотношения между владельцем компании и командой разработки.
  6. Внедрена Scrum-методология, что ускорило процесс разработки и сделало его понятным, прозрачным и управляемым для заказчика.
  7. Экономия бюджета за счёт удешевления сборки продукта. Автоматическая сборка значительно стабилизировала, упростила и ускорила процесс создания различных версий для поставки заказчикам. Время, затрачиваемое специалистом за сборку одной лицензии уменьшилось более, чем в 15 раз (10 минут против ~3-х часов). Это позволило высвободить дополнительное время для разработки, а также убрало зависимость от незаменимых ранее членов команды.
  8. Появилась возможность безболезненного добавления в команду новых разработчиков. Количество разработчиков на проекте увеличилось в 2 раза.
  9. Благодаря проведённой комплексной работе заказчик смог выпускать новые версии продукта в 2 раза быстрее, при этом количество подготовленного к релизу функционала также возросло в 2 раза.

Отзыв заказчика

Отзыв Дмитрия Евланова на консалтинг

“Дмитрий Горячко способен учесть интересы всех. Проект очень непростой, с большим объемом технического и организационного долга. И то, что удалось совершить серьезную организационную трансформацию не махая шашкой, сохранив людей и не допустив демотивации, — это дорогого стоит. Особо понравилось то, что Дмитрий не просто давал конкретные советы, а непосредственно управлял процессом трансформации девелопмент культуры. Крайне редкое сочетание технических навыков, эмпатии и навыков медиации. Далеко не каждый умеет быть лидером как для менеджмента, так и для инженеров.”

Отзыв Дмитрия Евланова на консалтинг
Дмитрий Евланов
СЕО и фаундер Simmakers.com
rect
Получите БЕСПЛАТНЫЙ чек-лист «Как понять, что ваш проект в опасности?»
photo

Приветствую! Меня зовут Дмитрий Горячко. Специально для вас я подготовил чек-лист, который поможет определить, в опасности ли ваш проект, и предоставит чёткое количественное измерение сложности ситуации.

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

Также чек-лист содержит большое количество практических советов. Это поможет вам самостоятельно продвигаться по решению проблем.