Людський фактор залишається самим сильним, але вигідним, ризиком у розробці


Изображение з сайту projectimo.ru

Навіть у такої продуманої і формалізованої сфері, як розробка програмного забезпечення, не перестає бути актуальним питання управління ризиками. Чи можна взагалі керувати невизначеністю, випадковими величинами?

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

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

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

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



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

Невипадково при описі ризиків виникає асоціація із спокусою. Розробники – живі люди, які не можуть постійно працювати з однаково високою ефективністю. Щоденні спокуси «відкласти на завтра», «раніше піти», «прийти пізніше», і так далі, мають накопичувальний ефект. Якщо N співробітників підуть на поводу у M спокус, це значно знизить загальну дисципліну і локальну продуктивність праці.

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



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

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

Так ми приходимо до найголовнішого питання – чи можна якимось чином зарезервувати «людського фактору» місце в списку ризиків і навчитися керувати ним?

Перше рішення, яке приходить в голову, – по можливості, позбавити всіх співробітників статусу «незамінний». Мова йде про такі підходи, як парне програмування або, наприклад, тестування, code review, ротація співробітників між різнотипними завданнями та інше колективне творчість. Сюди ж примикає створення великого резерву часу, що виділяється на завдання з урахуванням можливих ризиків. Однак це виходить далеко не завжди.

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

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

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

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


Изображение з сайту joyreactor.cc

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

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



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

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

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

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



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

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

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.