В книге Боба Боумана «Золотые правила. Стань чемпионом в том, что ты делаешь» мне очень понравился один момент. Речь там идет о необходимости иметь две цели: к одной ты стремишься сейчас, наличие второй поможет не впасть в депрессию после достижения первой.

1

Запуск

Когда вы запускаете IT-проект, большой или маленький, у вас автоматически появляется первая цель — выполнить поставленную задачу, а также и вторая — добиться, чтобы после завершения проекта компания ощутила положительный эффект и/или получила прибыль.

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

Но в проектных командах обычно нет роли для человека, думающего широко и даже глобально, того, кто смотрит на бизнес в целом. Чаще всего у тех, кто в компаниях занимается разработкой и внедрением IT-проектов, довольно конкретные цели. Очень часто конечной среди них остается как раз сдача проекта.

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

2

Долгосрочные издержки

В итоге проекты пишут по несколько лет, работают над улучшением производительности, переделывают архитектуру, добавляют фреймворки(набор шаблонов, инструментов для программной платформы) и новые графические интерфейсы. Но после запуска оказывается, что новые системы никому не облегчают жизнь. Например, для непосредственных пользователей решение стало только медленнее, так как раньше при помощи горячих клавиш они заполняли какую-то форму за 30-40 секунд, а с модной «клиент-серверной» архитектурой это занимает несколько минут, так как справочники хранятся на сервере, а сеть слабая. И вот вы уже достаете «пару добротных бревен и строгаете новые костыли», чтобы подпереть хорошую, современную, но неподходящую для целей бизнеса архитектуру.

Иногда забывается или не уточняется настоящий «юзер-флоу» (переход пользователей от одного сценария взаимодействия с интерфейсом к другому, пользовательский маршрут).

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

3

Реальная практика

Приведу пример из реальной практики. Я принимал участие в запуске новых self-checkout-решений (англ. self checkout - кассы самооблсуживания) для одной крупной ретейл-сети. Решение было разработано специально для конкретного ретейлера. Хоть оно и должно было работать в России, но разрабатывалось в Европе. Инженеры не первый раз создавали подобное устройство, они точно знали «как и что надо сделать», поэтому по ходу разработки менеджменту вопросов никто не задавал.

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

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

4

Что делать

Что делать, чтобы этого не происходило? Хороший вопрос. Об этом написано много книг, на эту тему проводят много тренингов. На мой взгляд, важно помнить, что, даже если вы сформировали хорошую проектную команду и выделили всевозможные ресурсы, проект не обязательно взлетит. Вернее, он, скорее всего, взлетит, но принесет ли он пользу компании — все еще вопрос открытый.

Чтобы польза все-таки была — необходим человек от бизнеса, мощный стейкхолдер, который будет помогать, регулярно общаться с проектной командой. Причем общаться в формате рабочих встреч, проводить реальные демо версии, да, тратить время важных и очень занятых людей. Без всего этого, успешно выполнив проект, вы должны будете запустить новый — по внедрению полученных результатов.