IT Manager ІТ в бізнесі Що хоче бізнес Олександр Башкиров

| 26.01.2018

Будь-який проект завжди пов'язаний з ризиками. І, напевно, найголовніший ризик, який так чи інакше стосується будь-якого проекту, - зробити «не так». При цьому «не так» можна зробити багато чого: від невірної оцінки ризиків до того, щоб пустити все на самоплив. Я спробую описати основні помилки, які робив я або мої колеги в проектах, а також навести рекомендації про те, як можна було б їх уникнути.

Я свідомо не буду писати тільки про ІТ-проекти, тому що, по суті, помилки є спільними для проектів всіх типів.

Помилка перша: головне - вплутатися в бійку

На жаль, абсолютним лідером за кількістю провалів і створених складнощів є підхід, при якому ми ставимо собі за мету «взяти проект за всяку ціну». Ресурси? Ні, не чули. Ну, або варіації: ресурси є! Те, що профіль іншого - трішечки не важливо. Перепрофілювали. А то, що java і delphi - технології різні ... ну так це так, фактор другого порядку. У нас же є програмісти, які, напевно, зрадіють можливості ... Так, а що delphi за вечір не освоїти? Шкода-шкода. Ну ладно, тоді два вечори є в наявності, о'кей. І так, проект пов'язаний з hiload.

Це, звичайно, найбільш одіозний з відомих мені прецедентів. Менш одіозні були іншими, але мали один спільний корінь: компанія, підрозділ, IP намагається взяти на реалізацію проект, який або непрофільний, або заздалегідь приречений на провал при поточних ресурсах. Варіації цієї помилки: «ось отримаємо фінансування авансом за проект, і тоді ...», «так що тут складного» і т. Д.

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

Що можна зробити, щоб не робити цієї помилки? З одного боку, все дуже просто: достатньо лише уважно і вдумливо оцінити свої сили і можливості для реалізації проекту. Зрозуміти, що він являє собою по суті для компанії: штатний проект (типова діяльність), трохи нестандартний проект (схожий на те, що вже робиться або робилося і є якийсь досвід в цій області), нестандартний проект (такого роду проекти безпосередньо не виконувалися, але компетенції хоча б частково є), нестандартний високоризиковий проект (подібні проекти не робилися і компетенцій немає) або просто проект в невідомої області (такі проекти не робилися і область проекту невідома). Якщо проект знаходиться в нижній області наведеної шкали ризику, то за нього можна братися і, швидше за все він буде реалізований. Якщо у верхній - то обов'язкова оцінка ризиків і розробка стратегій роботи з ними. Причому це має бути не просто «стратегія на папірці», писати її слід з розумінням, що, ймовірно, доведеться її застосовувати. Фактично для високоризикових або невідомих проектів потрібні не просто оцінки ризиків, а й солідний бюджет на їх покриття. Я стикався з ситуаціями, коли нові проекти такого типу робилися за принципом внутрішнього стартапу, на який виділяється певне фінансування і який можна було припинити в будь-який момент, причому не тільки з фінансових причин. Подібне ставлення до особливо великим і ризикованих проектів або проектів з високою невизначеністю мені здається досить розумним - з точки зору того, що стартап «коли що» закрити набагато простіше, ніж основну організацію. Та й контролювати його бюджет набагато простіше - немає витрат, які «розмазані» по іншим активностей.

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

Помилка друга: не по Савці свитка

Це ситуація, зворотна розглянутої вище, коли від перспективних проектів відмовляються тому, що компанія вважає, ніби не зможе виконати проект. Причини різні - брак ресурсів, наприклад. Або побоювання не витримати терміни і / або вчасно не зробити якісь суттєві частини проекту через відсутність досвіду, компетенцій і т. Д. До речі, я стикався з подібною позицією, і в 90% випадків виявлялося, що реальна причина полягає в тому, що компанія сумний досвід, і ось тепер, обпікшись на молоці, дмухає на воду. Фактично це означає, що для всіх проектів, крім штатних, запалюється «червоне світло». Позиція, насправді, має право на життя, правда, є декілька «але».

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

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

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

Що можна порадити, якщо ви, як РП або РПО потрапили в подібну ситуацію? Якщо ви бачите перспективу в проекті, постарайтеся її оцифрувати. А також оцифрувати ризики і ступінь ризиків. Розмовляйте мовою цифр. Можливо, варто почати з малого - зробити один невеликий проект, з мінімальними ризиками. Потім ще один. І так далі, поступово «розгойдуючи» корпоративні стандарти.

Помилка третя: помилка мотивації

Помилки мотивації команди проекту і пов'язаних з ним співробітників - відділ