Ненужные Идеи или Траектория серебряной пули

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

“Женитьба” Н.В. Гоголь

В своей практике я часто сталкиваюсь с мнением, что любую проблему можно решить, надо только “что то придумать”. Найти ту самую “серебряную пулю”, которая убьет трудности наповал. А лучше все и сразу! Не покупают программу – приделаем ей новый GUI, у сервиса низкая посещаемость – закажем рекламу на ТВ, не укладываемся в сроки разработки – наймем больше программистов. И посмотрим что из этого выйдет! должно сработать! если не сработает – опять будем что то придумывать! и опять! и опять!  Можно ли компенсировать проблемы подобным способом?

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

• Хорошие идеи – редкая находка
• Прежде чем что то придумывать надо изучить природу возникшей проблемы

Пуля на старте

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

Приведу пример из своей практики:

Я пришел к своему директору с предложением разработки нового проекта. Подготовил Видение, План работ, Оценку ресурсов, Проект договора. Сели, сделали грубую оценку стоимости -получилось убыточно. Шеф засомневался, и сказал, “Знаешь, нет, сейчас не те времена, чтоб тратить деньги на далекие и неопределенные перспективы. Нам нужны ресурсы на текущие контракты”. Я немного огорчился, потому что проект мне, как системщику, нравился, но возразить было нечего. Но потом он вдруг внезапно просветлел и заявил “Но если ты берешься организовать проект так, что там будет пользовательский интерфейс такой же классный, как вот мы недавно сдали (правда это был веб-проект, но ничего!), где, знаешь, можно все настраивать, как кубики, перетаскивать туда-сюда.  Тогда давай!!!”

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

Когда вы принимаете решение, о выделении ресурсов на какое то дело, вспомните слова Joel Spolsky:

“The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works.“

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

Рекомендации:

• Когда вам предлагают взяться за какой то проект, спросите, какие проблемы будет решать будущий продукт?
• Спросите – каким образом ваша компания намерена извлекать прибыль из создаваемого продукта? Это сразу накладывает на продукт важные бизнес-требования
• Не поддавайтесь навязыванию технических решений на стадии выработки бизнес-требований к проекту

Пуля в полете

Труднее всего остановить самого себя. На свою “гениальность” уж всегда надеешься. Но, умение остановиться, и понять проблему, очень важно.  В управлении проектом всегда что то идет не так как планировал. И заметить это совсем нетрудно. Сыплются жалобы пользователей, этапы работ не укладываются в календарный план, команда работает сверхурочно уже которую неделю, возникают новые задачи, которых никто не ждал, подводят заказчики или “аутсорсеры”. Трудно признать причину проблемы, потому что как правило, ее создал ты сам, своими руками.

И тут менеджер проекта попадает в ловушку “Выполнить план любой ценой”. Начинаешь рассуждать как Агафья Тихоновна из пьесы Н.В. Гоголя “Женитьба” (см. эпиграф). Сказав себе, что отступать некуда, фокусируешься на поиске “серебряных пуль” – генерируешь идеи, которые должны спасти ВСЕ, например:

• “Хорошо бы успеть выпустить релиз в пятницу вечером”
• “Еще пара недель без выходных и мы приведем дела в порядок”
• “А может постараемся, успеем в срок?”  ( это THE BEST )
• “Ну и фиг с ними с багами, потом исправим. Проект сдавать надо!”

Не знаю, кем считают себя менеджеры в таких ситуациях. Может быть, капитанами тонущих кораблей или командирами отрядов, попавших в окружение. Но их целью становится уже не “привести корабль в назначенный порт” или “выполнить поставленную боевую задачу” а “не утонуть” или “прорваться”. Специфика работы в проекте как раз в том, что потеря цели – это и есть неудача проекта. Менеджер проекта не станет героем, если он не достиг цели проекта, но зато “сохранил команду”, вы не на море.  Если целью проекта становится выживание, об этом надо хотя бы предварительно договориться со спонсорами. А тут то как раз возникают трудности. Или неопытный менеджер не осознает что делает, или боится приносить плохие вести, или руководство не готово гибко подходить к ситуации. Если вовремя не остановиться в авральном стиле работы, можно нажить большие неприятности, потому что авралы никак не решают проблему.  Почему мы не успеваем с релизом? Что будет через пару недель без выходных?  -  вот о чем надо себя спросить.

Типичная (но далеко не единственная) цепочка ошибок, приводящая к непрекращающимся сбоям в работе команды:

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

Стиль мышления “мне сказали – я делаю” не работает в управлении. Так же не работает подход “сейчас я быстро все исправлю”. В дальнейшем, такое пренебрежение наносит ущерб проекту и репутации менеджера.

Рекомендации:

• Аккуратно и тщательно работайте с требованиями
• Делайте, а потом корректируйте оценки на протяжении всего жизненного цикла проекта
• Планируйте и отслеживайте риски
• Планируйте и управляйте коммуникациями
• Несмотря ни на что не позволяйте вышеперечисленным процессам прерваться. Поддерживайте их хотя бы в самом примитивном состоянии
• Никогда не поддавайтесь панике!

Пуля на излете

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

В одном из проектов, в котором я принимал участие, высшее руководство хотело, чтобы конечный продукт выделялся своим пользовательским интерфейсом. Это должно было стать одним из маркетинговых преимуществ. Как руководитель группы разработчиков я предложил применить новую, многообещающую технологию построения UI. Концепция технологии давала впечатляющие возможности при всепроникающей управляемости. Я догадывался, что где то поджидают проблемы, но признаюсь, очень хотел попробовать новую технику, мой коллектив был бы первым в городе! Последний диалог  с директором был примерно таким “А вы обещаете, что с применением этих технологий сделаете в проекте такую же анимацию как у конкурентов? – Да, обещаю, мы уже попробовали, смотрите, у нас есть тестовый пример!” и работа “понеслась”.

По итогам авантюры:

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

Сейчас я бы предпочел потратить время и деньги на сбор требований (некоторые предпочитают  говорить  Requirements Development & Management) и нанял бы настоящего специалиста по проектированию UI.

Рекомендации:

• Сначала определите проблемы, потом предлагайте решения
• Заведите в коллективе опытного архитектора, который будет отвечать за концептуальную целостность (тут классические работы Брукса все еще актуальны)
• Ничего не обещайте – обосновывайте!
• Дисциплина важна! Все работают одними средствами, все схожие задачи решаются одним методом
• Тестовые примеры ничто, если они не отражают требования к продукту

Из чего сделана пуля

Мои наблюдения довольно очевидны, но я решил написать эту статью, потому что слишком часто вижу, как люди перешагивают через момент, когда надо разобраться в проблеме и приступают быстрому придумыванию решений.  Это происходит в первую очередь по 2ум причинам – некомпетентность и бесхарактерность:

1. Некомпетентность. Когда вы не знаете как вам поступить – вы изобретаете. В лучшем случае вы “изобретёте велосипед”. На сегодня в управлении накоплено достаточно опыта и ваши проблемы наверняка не уникальны. Учитесь, тренируйтесь, читайте книжки. К некомпетентности я так же отношу нежелание работать и разбираться в происходящем или удовлетворение сиюминутных претензий в ущерб качества продукта в целом (“да сделай ты ему эти 50 кнопок в тулбаре, пусть только отстанет”).
2. С бесхарактерностью не так очевидно но, я считаю это существенной причиной. Под давлением обстоятельств люди, отвечающие за решение, начинают изобретать идеи в собственное оправдание. Или принимают чужое мнение, даже если обоснованно считают его неправильным. Такое часто бывает в организациях с очень авторитарным стилем управления. Срабатывает армейский прием “командир сначала отреагирует, а потом уже разберется”. К сожалению, у каждого решения в проекте есть последствия, и они не заставят себя ждать. Хороший менеджер просто обязан уметь говорить “нет”, когда все вокруг говорят “да”.

Можно перечислить много других причин, но по-моему, все остальное, производное от этих двух. Причины во многом психологические,  а значит очень живучие и очень назойливые. Но при желании, справиться “серебрянной пулей” нетрудно – нужен неторопливый и обстоятельный анализ – что случилось и почему.  Только не надо бояться и нужно учиться.