Процедура запуску, I

Звідси випливає друге правило:

Правило 2. Для початку проекту необхідно виконати процедуру запуску проектів.

Процедура запуску дуже проста і включає такі основні етапи:

прийняття рішення про ініціацію проекту відповідальною особою,
написання обґрунтування проекту та оцінки витрат на проект,
призначення керівника,
ухвалення рішення про запуск проекту,
написання керівником плану робіт та прийняття його начальством,
виділення ресурсів.

Це зовсім невеликий набір цілком очевидних дій, щось на зразок загальної гігієни - чищення зубів, миття рук перед їжею тощо. І так само корисний. На жаль, ця найпростіша проектна гігієна багатьом просто невідома.

Потрібно звернути увагу на той важливий факт, що при запуску проекту рішення приймається двічі: перше рішення про те, щоб розглянути і проаналізувати ідею, і друге рішення - про запуск проекту.

Насправді тут є й завуальоване третє рішення – ухвалення плану.

Ентузіасти

Звичайно, всі ці перелічені вище події не зможуть статися, якщо дитина не буде зачата, тобто якщо проект не матиме батька - ентузіаста, який запропонував саму ідею. Має місце таке правило:

Правило 3. Без ентузіаста будь-який проект мертвий.

Ентузіаст має бути готовим подолати невеликі бар'єри, які ставить перед проектом процедура запуску - переконання соратників, написання обґрунтування, отримання схвалення керівництва на запуск проекту.

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

Обґрунтування

Звичайно, якщо в організації формальні бар'єри занадто високі (паперів потрібно занадто багато, до босу на прийом не пробитися, потрібні візи всіх директорів тощо), то організація втрачатиме інноваційні ідеї та розхолоджуватиме ентузіастів.

Але невеликі, невисокі бар'єри потрібні, бо якщо ентузіазм ініціаторів та готовність начальства настільки низькі, що немає сил навіть написати обґрунтування чи призначити керівника, то проект не потрібен.

Обґрунтування – перший із таких бар'єрів.

Обгрунтування може бути написане тим самим ентузіастом або замовлено комерційному відділу, воно може складатися не з десяти, а з двох сторінок, але без нього не можна. Якщо за проектом не вдається (чи нема кому) навіть написати обґрунтування, його не треба починати. Введемо чергове правило:

Правило 4. Проект не можна обговорювати без обґрунтування.

Зауважу, що обґрунтування може написати і розробник, якщо він є ініціатором чи прихильником ідеї. Не страшно, що він "не розуміється на комерції". Якщо ідея цікава, потрібно надати йому комерсанта для прояснення витрат, ринкових умов, майбутньої окупності.

Зауважимо, що важливим є сам факт наявності тверезого обґрунтування необхідності проекту та аналізу ризиків і витрат, а не доказ прибутковості проекту. Підстави для запуску проекту можуть бути різними - адже це не обов'язково прибуток.

Обґрунтування може бути і таким: "так, сайт явно не принесе нам грошей, але без сайту вже непристойно, у всіх конкурентів є" або "ця система не дозволить більше заробляти, але наведе хоч якийсь порядок тут, тут і тут за таких -Витратах на місяць на підтримку" або "диск з демо-версіями буде мати чисто іміджевий ефект і обійдеться в стільки-то".

Головне - потрібна твереза оцінкавитрат та ризиків. Керівництво має ухвалювати рішення, тобто йти на витрати та ризик з відкритими очима.

На жаль, дуже часто на цій стадії обходяться замінними міркуваннями на кшталт "та це нам майже нічого не варте", "у нас і так майже все є, залишилося небагато", "зробимо по ходу, паралельно", "та мені сусідський хлопець за 100 доларів все сліпає", покликаними просто замилити питання обґрунтування.

Про віртуальні обґрунтування майбутньої рентабельності типу: "обсяг ринку дорівнює півтора мільярдам доларів, якщо ми з нашим продуктом займемо 0,5%, або навіть краще за 1,5%, то це будуть величезні гроші." - навіть говорити не хочеться.

Керівник

Далі слід призначити керівника. Це може бути той самий ентузіаст або інший менеджер, але керівник має бути. Якщо ніхто не несе персональну відповідальність за проект, то проекту все одно, що немає. Кожен автомобіль, що рухається по дорозі, повинен бути забезпечений шофером.

Отже, ще одне дуже просте правило:

Правило 5. Немає проекту без керівника.

Хоча керівник не обов'язково повинен бути тим самим ентузіастом, який ініціював проект, певний ентузіазм щодо проекту він має відчувати. Рушійні сили його зараз неважливі (кар'єра, інтерес до ідеї проекту, прагнення показати себе, ін.), але керівник повинен мати рішучість виконати проект. І ця рішучість має йти зсередини, а не згори.

Керівника проекту має бути призначено якомога раніше.

Керівник має бути один

Тут слід обов'язково відзначити, що багато відповідальних не буває. Багато буває лише безвідповідальних.

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

- Керівник проекту потрібний. Кого призначимо? - Та ось хоч Володя з Максом - один продавець, інший технар. Якраз розберуться. Так, і нехай Пупкін їм допоможе з маркетингом.

Це вірний шлях до провалу чи створення "віртуального" проекту-зомбі, який ніби рухається. А призначені Володя, Макс та Пупкін думають, що робота якось там ведеться іншими двома товаришами. У семи няньок.

Правило 6. Керівник має бути один.

Слід додати також, що номінальний керівник (призначений з поваги або на безриб'ї), скажімо, великий бос, який в основному їздить за кордоном і переговорами в ролі керівника проекту - ще гірше, ніж відсутній керівник або згадані сім няньок. Віртуальний посібник призводить до віртуальних результатів.

План та відповідальність

Основна функція керівника - планування, тому що, по-перше, планування починається до будь-якого управління, а по-друге, план є квінтесенція відповідальності.

Адже план - це не програма дій і подій на кшталт програми ТБ, а письмове зобов'язання керівника, подібне до розписки при отриманні грошей у борг. Аналогія тут не поверхова, а глибока - адже керівник проекту бере у компанії ресурси у борг, а віддати має результатами проекту.

Таким чином, якщо план – це питання зобов'язань та відповідальності, то керівник без плану – особа безвідповідальна.

Це просте міркування пояснює, чому так важко буває досягти планів від середнього менеджера. З цим стикався будь-хто, хто запускав проекти та призначав керівників.

Працює менеджер багато, енергійно, листи шле щогодини, а ось планів чомусь не пише. Здавалося б, нунапиши програму дій, затверди у начальства і дій, що тут складного? Але ж насправді це питання не програми дій, а відповідальності!

Отже, тут потрібен моральний вибір та прийняття ризикованого рішення – взяття він відповідальності. І менеджер часто несвідомо ухиляється від цієї відповідальності.

Тобто багато працювати він готовий, присягатися на вірність проекту готовий, робити різні обов'язкові речі - теж, а скласти план і прийняти на себе відповідальність - ні.

Цікаво, що на старті проекту плани пишуться все-таки досить легко. І зрозуміло, чому проект новий, терміни довгі, до кінця проекту далеко, відповідальністю поки і не пахне. Можна не ламати голову, цифри брати приблизні, ніхто перевірити не зможе, а покарають за зрив чи ні - то ще півроку! Якось розрулимо цю справу.

Саме тому початкові плани такі неточні.

А ось у середині проекту, вже після зриву перших термінів середній менеджер зазвичай тихо, але наполегливо чинить опір будь-яким спробам отримати від нього наступні - уточнені - плани. Тому що тепер можливе настання відповідальності - близько і явно видно. Пороті на летучці минулого понеділка місця ще болять.

- Дай уточнений план випуску бета-версії нарешті! Коли ви дійсно її зробите, а не так, як минулого разу! - Та я прямо зараз можу сказати, без писанини - там майже все готово, скоро випустимо. - Ну так запиши це коротко на папері і постав дати! Коли точно? - Та за вихідні випустимо. У понеділок точно випущу. - Ось і прийшли мені листа з цією датою, і там докладно напиши, що саме буде випущено. Функціональність і недоробки, які потім виправите. - Добре, на початку того тижня у всьому розберуся і надішлюплан. - Як це - план на початку тижня?! Адже в понеділок уже має бути бета, ти ж щойно сказав. План мені потрібен сьогодні! - Ну, добре, добре. Тільки я сьогодні кров із носа маю зібрати проміжне складання і віддати тестувальникам (виправити помилку, з'їздити до замовника, написати завдання для програмістів). А план завтра напишу.

Далі – за індукцією. Тижня минають, а уточненого плану все немає. І бета-версія (сайт, продукт, каталог, збірка) все в тому ж положенні – майже готова.

Отже, якщо керівника призначено, потрібно терміново зробити його повноцінним керівником, тобто покласти на нього відповідальність. А саме – вимагати від нього план.

Правило 7. Проект не можна запускати без плану, написаного особисто керівником проекту.

Оскільки ключовий момент перемикання відповідальності – рішення, то план має бути прийнятий начальством. У цей момент відповідальність за виконання переключається на керівника проекту, відповідальність за забезпечення ресурсами – на начальство, яке прийняло план.

Звичайно, є й інший метод – спуск плану зверху. Начальством заданий термін та вимоги до проекту, далі – проси ресурсів (а ось чи дадуть їх і скільки – це вже як пощастить) і працюй хоч до четвертої ранку; принаймні, йди додому пізніше боса.

На жаль, у такій ситуації з керівника проекту по суті не вийде відповідальна особа. Як він може бути по-справжньому відповідальним за чужі плани та обіцянки? Фактично керівник проекту з вільної людини, яка обдумано взяла на себе зобов'язання, перетворюється на задерганого виконавця, який відчуває безнадійність, тому що ні успіх, ні провал від нього майже не залежать. І навіть щедрі премії наприкінці проекту самої ситуації зі зсувом сферивідповідальності не змінюють.

Кілька разів мені доводилося спостерігати подібні ситуації у розробці програмного забезпечення, і вони майже завжди закінчувалися розвалом проектної команди та зривом проекту.

Метод спуску планів зверху найбільш схожий на сталінську модель індустріалізації, коли і жорсткі плани, і сувора відповідальність наступають невідворотно, як дощ чи сніг. І батіг, і пряник у руках головного боса в цій моделі повинні бути майже такими ж вагомими, як життя і смерть. Так, і потрібна ще одна умова: виконавець не повинен мати можливості втекти. На щастя, за умов вільного ринку праці ця модель не працює.

Прості та ефективні поради, як саме писати плани щодо розробки програмного забезпечення, даються в статті Джоела Спольськи "Painless Software Schedules" ("Планування розробки малою кров'ю"), тому я дозволю собі не заглиблюватися тут у технічні та організаційні подробиці.

Правило 8. Проект не можна запускати без ресурсів.

Ну, це взагалі очевидно, скажете ви. Так, та не так. З різних причин боси всіляко тягнуть із виділенням ресурсів на вже затверджений проект.

У принципі, словами визнається необхідність виділення грошей, техніки, людей, приміщень. Але або ресурсів поки що немає, або бос не наважується відібрати їх у інших своїх підлеглих, знаючи, що будуть неприємні сцени, або просто не доходять руки.

Виникає погана петля випрошування: як би менеджер проекту повідомив боса про те, що ресурси потрібні і які саме, і той погодився. Плани та заявки затверджені.

Але насправді ресурсів не дали: у бухгалтерії немає підписаної заявки на гроші, приміщення не звільнили, техніку не купили, людей не відпускають із інших проектів, кадровики додаткових людей не шукають – не булонаказу.

Менеджер знову приходить до боса, а той дивиться на нього з надією – а може, так упораєшся? З грошима в магазин і дурень сходить, а от ти спробуй без грошей!

Наново відбувається торгівля, суперечки. Менеджер знову вибиває вже одного разу обумовлені ресурси. Щось нарешті виділяють, чогось знову не дають. І ще, і ще раз, і так по колу.

Зауважимо, що весь цей час годинник проекту цокає - адже план затверджений і час уже пішов!

Я можу тут порадити лише одне - постаратися не сприймати дійсність такої, як вона є, і не працювати з урізаними ресурсами.

Навпаки, у разі затяжок з виділенням ресурсів потрібно намагатися формально переносити терміни в плані: немає ресурсів - почекаємо, але запишемо це в план. Зазвичай босу в момент чергової торгівлі про ресурси цього заперечити нічого.

Такий формальний підхід може не допомогти з ресурсами (особливо, якщо страшний секрет начальства полягає в тому, що їх насправді немає), але принаймні зніме з менеджера відповідальність за чужі проблеми.