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

Зображення з сайту projectimo.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зображення з сайту joyreactor.cc

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

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

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

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

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

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

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

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

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

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