Молчание разработчика: история о том, как отсутствие митингов и высокий кворум доверия превратились в 6-месячный факап

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

Когда-то мы разработали отличный продукт — Service Desk. Это интерфейс для заказчика, с помощью которого он может отслеживать ход выполнения своих проектов и взаимодействовать с нами как с подрядчиком в одном информационном пространстве. Штука удобная, тут можно:

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

Казалось, что делать тут нечего, но все вылилось примерно в полгода. Мы очень сильно ошиблись в части сроков. Возможно, технический специалист, владеющий выбранной нами технологией, мог бы прикинуть риски и увеличить срок до двух или трех месяцев. Но посоветоваться нам и ему внутри компании было не с кем. Поэтому с точки зрения ожиданий заказчика, которые были завязаны на месяц, и в итоге работы на протяжении 6 месяцев — все это, конечно, выглядело как УПС.

ТРИК был экспериментом, которому мы решили уделить чуть больше внимания. Service Desk не стал исключением. За основу была взята технология разработки, по которой работают подобные сервисы. Однако опыта использования этой технологии внутри компании не было. Но кто не пробует, тот не развивается.

Можно ли было ничего не делать, потому что Service Desk работал и так? Скорее нет, чем да. ТРИК сильно ушел вперед, а Service Desk был реализован по логике, от которой мы уже ушли. Конечно, можно было использовать тот технический опыт, который имеется в компании, но нам очень хотелось попробовать что-то новое и интересное. По итогу у нас все равно получился результат, потому что нам хватило терпения и средств дойти по выбранному пути до конца.

Вопрос цены, которую мы за это заплатили:

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

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

Декомпозировать задачи на части, более трепетно отнестись к планированию трудозатрат на реализацию каждого пазла в общей картине. Ну и конечно же, пытаться управлять изменениями. Помогло бы это? Скорее, нет, чем да. Но это помогло бы правильно объясниться перед ключевой заинтересованной стороной проекта. Факапа мы вряд ли избежали бы, но заказчик был бы вовремя предупрежден об этом. Кто знает, может быть мы бы смогли добавить ресурсов или вообще свернуть проект через 1–2 месяца. Но вместо этого мы выдали кредит доверия разработчику. К слову, он никогда не давал повода не доверять ему и в других проектах качественно и в срок выполнял свою работу. Здесь должно, наверное, всегда закрадываться сомнение, и менеджер не может убирать руку с пульса в плане контроля.

Доверие — дело тонкое. Заслужить его достаточно сложно, а подорвать можно практически на ровном месте. Человек, которому доверяют, обязан нести за это ответственность. В случае с проектным управлением это равно тому, что он обязан сообщать о рисках по срыву сроков своевременно, как только начал хоть как-то это осознавать. Безусловно, эти риски могут не произойти, и, может быть, все будет хорошо. Но ответственность за доверие, которое оказано, безусловно, лежит на этом человеке. Вряд ли его расстреляли, когда узнали бы об адекватных причинах срыва сроков по подобному кейсу. Да, переоценил свои возможности. Да, не хватает компетенций, и медленно идет освоение технологии. Нужно рассказать об упущении. Но, к сожалению, в реалиях на открытые диалоги способны единицы. Павел Алферов про одну из национальных особенностей: «Сверху не дают, а снизу не берут». А в нашем случае было так: доверие, равное ответственности, оказали. Но на открытую обратную связь доверия в ответ не получили. Поэтому, спустя какое-то время, больше о доверии к этому человеку говорить не приходилось.

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

Несмотря на то, что новый модный и дорогой Service Desk введен в промышленную эксплуатацию, у нас есть к нему вопросы по развитию и исправлению ошибок. Кто теперь будет отвечать за развитие и маленькие баги, если тот, кто его разрабатывал, уже не с нами? Да, это проблема, но мы справимся. Более того, по итогам разработки понятно, что у этой технологии есть и будущее внутри компании. Ряд смежных основных сервисов точно так же можно постепенно переводить на новую технологию. Теперь-то мы уже имеем примерное представление о том, что нас ждет. При этом у нас уже есть база и опыт управления подобными разработками.

Самый сложный путь пройден, компонентная база и те сложности, из-за которых съехали сроки Service Desk так или иначе решены, а применять этот инструмент уже не так трудоемко, как разрабатывать.

О потерях скажу так. Из-за того, что мы своевременно не выполнили эту задачу в середине 2024 года, это не позволило нам закрыть те планы, которые были у нас по основному продукту — ТРИКу. Мы увеличили технический долг проекта и на сегодняшний день вынуждены бежать более быстрыми темпами, добавлять ресурсы, чтобы доделать те инструменты, без которых заказчикам будет сложно работать. Хорошо, что многие вещи в системе реализованы на базовом уровне, мы уже используем их и видим плюсы и минусы. Что-то нужно отрефакторить, что-то — пересмотреть и переработать. Это нормальная история в разработке подобных продуктов. Но мы сдвинули сроки по выполнению обязательств и, соответственно, пришли к увеличению бюджета. В этом случае инвестор попал на дополнительные полгода инвестиций за то, что должно было работать уже в конце 2024 года.

Учиться планировать, проводить более детальный анализ, взвешивать плюсы и минусы каждого решения. Если на это нет времени, то имейте хотя бы несколько планов развития событий. Есть оптимистичный план и есть пессимистичный. Нельзя заявлять инвестору, что вы сделаете все по оптимистичному плану. У каждого проекта есть сроки, иначе это не проект. У сроков есть заказчик. Заказчик всегда будет очень плохо реагировать на изменение сроков. Этот тезис можно применять как аксиому: «Если сроки были озвучены, то изменить их в голове заказчика очень тяжело». Без сроков тоже вряд ли кто-то согласится выдать несколько лишних миллионов. Поэтому у заказчика должна быть хотя бы вилка по срокам и критерии достижения результата при определенных требованиях заказчика. Ведь не всегда добавление ресурсов сокращают сроки, правда?

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

Больше интересной информации из мира ИТ-разработки, управления проектами и личной жизни тут —