Хотите узнать что такое управление рисками и как с ними справляться с ловкостью ниндзи?
Тогда добро пожаловать под кат!
(В этой статье изложены мысли, навеянные творчеством Тома ДеМарко, и скорее всего статья будет неинтересна тем, кто уже знаком с его произведениями)
В 1988 году в городе Денвер было принято решение построить новый аэропорт вместо старого. Существующий на тот момент аэропорт не отвечал потребностям растущего города, и был непригоден для расширения. Был выделен бюджет, началось строительство. Но, к сожалению, проект не удалось завершить в срок. Причиной задержки оказалось не написанное вовремя программное обеспечение. Аэропорт был оборудован низкими узкими тоннелями, предназначенными для транспортировки багажа. Программное обеспечение должно было сканировать штрих-код багажа и направлять его в нужном направлении по сети тоннелей. Поскольку в силу незавершённости ПО доставка багажа оказалась невозможной, аэропорт простаивал вплоть до готовности ПО. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока программисты второпях пытались играть в догонялки. А время – деньги. Упущенная выгода + убытки составили полмиллиарда долларов… СМИ уничтожила репутацию организацию-поставщика ПО, возложив всю вину на неё.
А теперь давайте представим, что менеджеры этого проекта потратили полдня своего драгоценного времени и занялись оценкой рисков, проведя мозговой штурм. Представим, что они собрались, и проанализировали, а какие убытки они понесут, если взлётная полоса или ПО не будут готовы вовремя, а также подумали, как можно сократить убытки в случае форс-мажора. Ей-богу, сеть крошечных туннелей — не единственный способ транспортировки багажа! Если бы было потрачена пара дополнительных миллионов долларов на постройку чуть более просторных туннелей, то можно было бы транспортировать багаж при помощи дешёвой рабочей силы или небольших грузовичков. Два миллиона — гораздо меньше, чем полмиллиарда. В конце концов, можно было даже не вкладываться в расширении туннелей, можно было бы использовать ездовых собак! Нанять кинолога, договориться с владельцем ближайшего питомника для беспризорных собак, и начать дрессировку. Если бы ПО было готово в срок, то в шаурмячных аэропорта цена хот-догов осталась бы неизменной, но вот в случае трудностей ездовые собаки смогли бы спасти положение. В любом случае, это хоть какая-то подстраховка. Но тут есть одно но. О таких вещах нужно задумываться заранее. Если в назначенный день сдачи проекта прибегает подрядчик с криками «шеф, всё пропало!», то тут уже поздно строить новые тоннели или дрессировать собак, потому что пока вы это доделаете, работы подрядчика наверняка приблизятся к логическому завершению.
Когда вы закладываете в бюджет проекта потенциальные убытки от риска помноженные на вероятность риска, это называется сдерживанием риска. Риск либо наступит, либо нет. Если не наступит, то ваши денежки останутся при вас. Если наступит, то, возможно, дополнительных денег, которые вы заложили в бюджет, окажется недостаточно. Но если вы оцените все риски, и какая-то часть из них наступит, а какая-то нет, то вы, вероятно, уложитесь в бюджет.
Когда вы заранее тратите деньги, чтобы минимизировать убытки наступления риска, это называется ослаблением риска. Например, когда вы нанимаете кинолога для дрессировки собак. Неважно, наступит риск или нет, кинолог будет кушать и веселиться за ваш счёт.
Давайте изобразим соотношение ослабления и сдерживания рисков для строительства аэропорта.
Известно, что подобную программу другая команда программистов делала в два раза дольше. К тому же программисты постоянно жалуются, что им не удаётся догнать график, поэтому будем считать, что вероятность поспеть в срок — 50%. На самом деле, если вы знакомы с диаграммами рисков, то согласитесь, что вероятность наступления самого оптимального сценария из всех возможных равна нанопроценту, но мы, подобно руководителям стройки, немного завысим ожидания и будем считать, что вероятность успеха равна 50%. Как в одном бородатом анекдоте: либо получится, либо нет, поэтому 50%. В IT вообще в большинстве случаев временные и вероятностные оценки даются интуитивно и «с потолка». Итак, вероятность риска 1\2, цена — полмиллиарда, на сдерживание риска будем закладывать половину от полмиллиарда. Для ослабления риска потребуется несколько месячных зарплат кинолога, тонна собачьего корма, + зарплата уборщика, прибирающего за собаками, живущими в недостроенном аэропорту. Ну, или цена на более просторные тоннели — на ваш вкус. Примерно это будет выглядеть вот так:
Как видите, ослабления риска в конкретно данном случае выглядит гораздо выгоднее. Конечно, если риск не наступит, то вы потратите ресурсы, которые могли и не тратить. Но, с другой стороны, если наступит, а вы не подстраховались, то последствия будут катастрофическими. Это как пожалеть деньги на страховочный трос, когда вы собираетесь пройтись по канату. Ослабления риска гораздо дешевле, чем его сдерживание, и его выгода очевидна. Но давайте рассмотри обратную ситуацию — что если сдерживание риска гораздо дешевле, чем его ослабление? Значит ли это, что в таком случае нужно сдерживать риск? На самом деле, не всегда. Тут нам поможет философия воина.
Знакомьтесь, это Беззаботный Фермер. Он знает, что чем усерднее он будет поливать и пропалывать своё поле, тем более богатый он соберёт урожай. Картина мира Беззаботного фермера выглядит примерно так:
Чем больше постарался, тем больше получил. Зависимость экспоненциальная: со временем за те же усилия получаешь большее вознаграждение (растёт квалификация и положение в обществе, увеличивается пассивный доход и т.п.), до тех пор, пока не будет достигнут какой-то фиксированный потолок. Всё предсказуемо и просто.
А это Бесстрашный Воин. Воин может получить тысячу мелких ран, но продолжать твёрдо стоять на ногах; до тех пор, пока не получит фатальный удар. Во время противостояния двух сторон, каждая из сторон пытается по-максимуму реализовать фатальные риски противника. Утомить противника до смерти гораздо менее эффективно, чем нанести просчитанный удар в самое сердце. Для воина формула «больше усилий — больше вознаграждение» не работает. Он может лишиться всего из-за одной единственной ошибки. Для концепции рисков верны обе философии — и землевладельца, и воина — но концепция воина всё же ближе. Риск либо наступит, либо нет. Это либо приведёт к провалу проекта, либо нет. Со щитом или на щите. С другой стороны, мы живём не в древней Японии, и у нас не принято в любой непонятной ситуации рубить провинившимся головы налево и направо. Не каждый проваленный проект означает распад организации и конец карьеры руководителя. Из любой, казалось бы самой безнадёжной ситуации, можно постараться извлечь хоть какую-то пользу. Можно завершить проект с урезанным функционалом, сменить целевую аудиторию, использовать созданные наработки в следующем проекте, сделать выводы о причинах провала проекта и постараться не допустить подобного в будущем. От этого провал не перестанет быть провалом, но хотя бы какая-то часть ваших усилий окупится.
Следующим ходом белые ходят конём на e5. Если чёрные побьют ферзя, то последует мат:
7… С:d1 Чёрный слон рубит белого ферзя
8. C:f7+ Kp:e7 Белый слон, под прикрытием коня ставит шах чёрным. У чёрных единственный возможный ход королём на e7
9. K:d5# Второй конь на d5. Мат
Есть возможность срубить ферзя противника и позволить поставить себе шах, но если противник сможет реализовать появившиеся риски, то вы проиграете партию. Это — фатальный (или критический) риск для вашей партии.
Рассмотрим пример из командной интеллектуальной игры — доты, где каждая команда состоит из 5 человек. Чем больше локальных стычек выигрывает тот или иной игрок, тем сильнее становится его персонаж, и тем больше шансов у его команды выиграть партию. Однако даже если одна команда раз за разом побеждает, и, казалось бы, надежды уже нет, одна единственная ошибка игрока из доминирующей команды может означать проигрыш для всей команды. Если в шахматах цель — срубить короля, то в доте цель — срубить источник силы команды противника (мировое древо «белых» или магический ледяной трон «чёрных»). Бывает, что игрок рискует, нападая на более слабого игрока из команды противника, или же нападая вдвоём на одного. Риск заключается в том, что на самом деле это может быть западня, и игрока подстраховывают из засады. Если двое игроков попали в хорошо организованную засаду, то ближайший игрок скорее всего будет «убит» и на время до «воскрешения» окажется вне игры, а второй игрок может попытаться спасти его (с риском тоже оказаться на какое то время вне игры) или же бежать со всех ног, пока команда противника расправляется с первым игроком. Если второй игрок рискнет и тоже «погибнет», то команда останется в меньшинстве. После этого команда противника может начать полномасштабное наступление, и, пользуясь численным преимуществом, сломить оборону и уничтожить «источник силы» противника.
Это похоже на финальную битву из какого-нибудь боевика, когда один персонаж на протяжении всей драки получает множество люлей и вообще выглядит на фоне фаворита поединка полным слабаком, но в конце каким-то чудом отправляет таки противника в нокаут. Да, философия воина, она такая. Недостаточно просто кидать дальше, прыгать выше, бить сильнее и иметь больше опыта. Нужна мудрость и отвага, чтобы предвидеть возможные риски.
Давайте разберём, что проигравшая команда делала неправильно. Может быть им не стоило нападать и рисковать попасть в засаду? На самом деле, стоило. Риск и выгода ходят рука об руку. Окупившиеся риски приближают к победе. Кто не рискует, тот не пьёт шампанского. Другое дело, что рисковать надо с умом. В данном случае, второму игроку, когда он понял, что дело пахнет жареным, стоило спасать свою команду, а не своего напарника. С другой стороны, если вы вынуждены бросать товарища в беде — это явный признак того, что вы что-то делаете не так. В данном случае, следовало ослабить риск, предварительно проведя разведку. Да, это потребовало бы дополнительных затрат ресурсов и времени, но это существенно сокращает риски. Тем более, что команда доминировала и могла позволить себе потратить немного ресурсов на разведку. Видимо, ощущение скорой победы одурманило их, и они напрочь забыли о возможных рисках. Неуважение противника — это фатальная ошибка. Запомните, любые отношения между людьми строятся на взаимоуважении.
А теперь вернёмся к вопросу, а если сдерживание риска гораздо дешевле, чем его ослабление, то стоит ли в таком случае сдерживать риск? Напомню, что сдерживание риска = вероятность риска * убытки от наступления риска. Если риск наступит, то вам потребуется заплатить полную стоимость, которая может в разы превосходить сумму, заложенную в сдерживание риска. Если у вас нет возможности заплатить эту сумму, и это ознаменует провал проекта, то, на мой взгляд, лучше всё-таки заняться ослаблением риска. Если и ослабление риска не представляется возможным, то стоит хорошенько задуматься, а стоит ли вообще браться за этот проект. По-моему, разумнее получить половину от возможной прибыли, чем рисковать лишиться всего. Разумеется, вы не сможете проконтролировать все риски. Риск и выгода ходят рука об руку, поэтому иногда имеет смысл просто рискнуть. Вы не сможете гарантировать, что метеорит завтра не упадёт на ваш дом, но это не повод, чтобы не обзавестись собственным жильём. Может быть упадёт, а может быть и нет. Но дело того стоит! Но, с другой стороны, это не повод, чтобы не подстраховаться на случай, если всё-таки упадёт. Небольшая сумма денег в банке, достаточная для аренды жилья на несколько месяцев, вполне сможет сдержать риск замерзания от холода на улице.
В случае инновационных технологий, управление рисками становится довольно тонкой игрой. С одной стороны, работа с новой технологией сулит много рисков, но с другой, не рискнуть ей воспользоваться означает рисковать позволить конкурентам обойти вас. В данном случае, не рисковать — гораздо больший риск, чем рискнуть (звучит довольно замысловато, да?). Как я уже говорил, по-моему, разумнее получить половину от возможной прибыли, чем рисковать лишиться всего. Разумеется, тут нужна оценка конкретной ситуации. Уменьшение прибыли может гарантированно привести к выдавливанию вас с рынка конкурентами, если вы изначально не имели никаких козырей в рукаве. Составить какой-то универсальный алгоритм действий в данном случае не получится. Как говорил фельдмаршал Гельмут фон Мольтке, ни один план не выдерживает боевого столкновения с противником. Понимание текущей ситуации в тандеме с прогнозированием полезны на любой стадии проекта.
В ситуации с аэропортом в Денвере вся вина была возложена на конкретных исполнителей, хотя фактически ответственность и убытки легли на городской муниципалитет. Как управленцы могли бы понять, что они что-то сделали не так? Я заметил следующую закономерность: если маленькая неудача приводит к более большим и критическим последствиям, значит где то в управлении рисками допущен промах. Например, если из-за неготовности ПО простаивает весь аэропорт. Или, например, если из-за отключения электричества не работают сигнальные огни (для таких случаев можно запастись резервными генераторами). Если из-за ошибочного нажатия не той кнопки половина земного шара улетает в космос в виде осколков. А вот не надо кнопку от ядерного чемоданчика располагать рядом с кнопкой наливания кофе в кофейном автомате в холле, ага. Для управленца это выглядит так: какой-то исполнитель ошибся, нажал не ту кнопку, и теперь Земли нет, вся вина лежит на исполнителе. Ну а исполнителю кажется, что он ошибся совсем чуть-чуть, просто спросонья ударил не по той кнопке. Если есть ощущение незначительности ошибки, и оно звучит правдоподобно, то это сигнал о том, что управление рисками было проведено из рук вон плохо. Это, конечно, не оправдывает исполнителя, уничтожившего человечество. А вот не надо работать в конторах, в которых корпоративная политика предполагает обязательное наличие кнопки от ядерного чемоданчика в каждом кофейном автомате, ага. Ну, или хотя бы, не надо подходить к этим автоматам ближе, чем на 3 метра. Также можно попробовать добиться изменения корпоративной политики или обнести эти автоматы ограждениями. К сожалению, в большинстве компаний «инициатива наказуема», поэтому вам придётся устанавливать ограждения в своё личное время, за свои деньги, а также нести ответственность по всем рискам, связанным с этими ограждениями, даже если вы не управленец и не имеете полномочий и возможностей для управления этими рисками.
Возможен и другой случай — если риск лежит на поверхности, периодически приносит кучу проблем, но все его игнорируют, то исполнителю будет казаться, что ошибки неизбежны, как и проблемы, которые они приносят. Поскольку к проблемам будет выработано привыкание, не будет ощущения незначительности ошибок и значительности их последствий, а будет ощущение адовости происходящего.
Жили-были две команды, трудящиеся в разных городах на благо одного стартапа. Первая команда состояла из продукт-овнера (замдиректора) и его помощника. Оба они совмещали функции руководителей, аналитиков и тестировщиков. Вторая команда состояла из нескольких программистов, тестировщика и тим-лидера. Занимались они автоматизированным сбором и переработкой информации, взятой из интернета, и публикацией её на своём сайте. Ну а поскольку источники, из которых собиралась информация, имели разный формат, и могли изменяться по прихоти разработчиков этих источников, то не всегда получалось корректно собрать с них информацию. С этой целью тестировщик круглыми сутками сравнивал информацию из источника с информацией на сайте проекта. Найдя ошибку, тестировщик заводит на доске соответствующую карточку с багом, программисты её исправляют, и в следующей версии программы подобная информация достаётся из источника корректно. А в другом городе другой тестировщик — помощник овнера — контролирует качество. Найдёт он давний, уже исправленный баг, но не заводит карточку, а докладывает продукт-овнеру. Потом программисты бодро рапортуют, что дескать, этот баг уже исправлен, мы только что передостали информацию для конкретно данного случая нашим самым свежим алгоритмом, и всё прошло без ошибок. Овнер не доверял программистам, и считал, что они покрывают себя и тестировщика, который не находит багов. К сожалению, в силу специфики проекта не было возможности передоставать из источника всю информацию за всё время с выходом каждой новой версии: во-первых, объёмы информации были велики, а, во-вторых, информация со временем теряла свою актуальность и ценность. В общем, спустя какое-то время, чтобы донести до удалённой команды серьёзность ситуации, овнер начал угрожать увольнением тестировщика и наказаниями для всей команды, а тим-лидер не стесняясь в выражениях за глаза бранил помощника овнера, и рабочая атмосфера стала не очень рабочей.
Можно ли было заранее спрогнозировать эту ситуацию? Это было бы непросто, но возможно. Достаточно было поочередно представить себя на месте каждого из участников процесса, учесть его должностные обязанности и представить, что именно он будет делать и с какими трудностями столкнётся. Овнер из другого города должен следить, чтобы удаленная команда не прохлаждалась и не бездельничала, а также задавать общее стратегическое направление проекта. Помощник должен ему в этом помогать. Команда должна работать. Естественно, при отсутствии полной прозрачности процесса, к овнеру в голову могут закрасться подозрения. Тем более, что полная прозрачность не могла быть достигнута, потому что ни овнер, ни его помощник никогда не занимались программированием, и соответственно не могли объективно оценить продуктивность удалённой команды. Соответственно, единственный возможный способ не допустить конфликта — сделать так, чтобы «надсмотрщики» не могли ни к чему придраться. Нужно было спрогнозировать этот риск и принять меры. Но даже когда риск наступил, тим-лидер и овнер не стали искать пути решения проблемы. Они стали искать виноватых. Проблему же частично решил программист, предложив на тестовой площадке удалять и перезаполнять данные за предыдущий месяц каждую неделю, чтобы помощник овнера искал ошибки в данных, полученных самым свежим алгоритмом. Основная проблема тут — отсутствие доверия и уважения между командами в разных городах, и эта проблема не была решена. Но теперь у овнера хотя бы стало меньше поводов для недовольства.
Мораль: решайте проблемы, а не перекладывайте ответственность. (Ответственность за весь проект в целом в любом случае лежит на руководителе проекта, подробнее об этом можно почитать в чёрной книге менеджера.) Под решением проблемы подразумевается анализ ситуации, поиск фундаментальной причины проблемы, оценка целесообразности по ослаблению риска для предотвращения повторения проблемы в будущем, поручение мероприятий по ослаблению риска подчинённым, контроль выполнения этих мероприятий. Разумеется, перед этим нужно раздать указания по устранению последствий уже наступившего риска.
Была одна программа для бухгалтерского учёта, условно назовём её программой А. Было решено написать новую программу Б, передающую данные программе А через базу данных. В новую программу Б вводились более детальные данные о процессе производства, нежели в старую программу А, затем в Б вычислялись необходимые данные и передавались в А. Пользователи должны были вводить данные в Б, а затем пользоваться старой программой А. Б использовалась не только для передачи данных в А, но и давала пользователям некоторые новые возможности. Разработчик новой программы Б не знал бизнес-логики программы А, и языка Delphi, на котором она была написана, поэтому уточнил у автора А какие данные и в какую таблицу передавать.
К сожалению, в этой организации не было отдела тестирования, а аналитик, знавший бизнес-логику, по совместительству была начальницей, и предпочитала перекладывать тестирование и частично аналитику на своих подчинённых — программистов. Если программист неверно понимал довольно абстрактные технические задания аналитика, то непроверенная аналитиком и неверно реализованная программа отправлялась к пользователю.
Чтобы у пользователей не возникло соблазна продолжать вводить данные в старой программе, было решено принудительно убрать у них такую возможность, резко переведя их на новую, недостаточно протестированную, программу. Руководительница дала задание автору старой программы внести в неё правки, запрещающие вводить данные, и тот оперативно выполнил задание. Не знаю, может быть, автор старой программы наивно полагал, что на этот раз тестирование было проведено. Может быть, сыграла роль вышеописанная проблема привыкания к неизбежности проблем. Как бы то ни было, про риски он не сказал. Ну а может быть, он подсознательно понимал, что ему, как единственному человеку, который в курсе бизнес-логики старой программы (если не считать руководителя-аналитика, разумеется), придётся проводить тестирование и он провалит сроки своей текущий задачи. Как бы то ни было, недопротестированная программа была принудительно поставлена пользователям. Ожидаемо, обнаружилось, что некоторые частные случаи не были учтены. Из-за этого работа пользователей несколько раз стопорилась на несколько часов, и в программу спешно вносились правки. Ответственность за это была возложена начальницей на разработчика новой программы.
Давайте разберём, какие ошибки были допущены в данном случае с точки зрения управления. Если в предыдущей истории тимлидер хотя бы теоретически мог предвидеть риски и ослаблять их, то у данной руководительницы, никогда не занимавшейся программированием, такой возможности не было. Поскольку руководительница должна была руководить IT-процессами, которых она не понимала, она постаралась переложить побольше ответственности на тех, кто их понимал, — на конечных исполнителей. Но сделала это в неявном виде. То есть после парочки неверно просчитанных рисков, программистам должна была стать понятной вполне чёткая и не скрываемая позиция начальницы: ты программист, делаешь всякие магические штуки, в которых я ничего не смыслю, ты в ответе за всё что происходит на проекте. Но напрямую задание изучить и начать управление рисками никому не выдавалось. Случается, что руководитель в каких-то вопросах некомпетентен, но это не беда, ведь у него есть подчинённые, которым можно поручить те или иные задачи. Не умеешь рисовать — поручи это дизайнеру, не умеешь писать сайты — поручи это программисту, не умеешь управлять рисками — поручи это старшему программисту, не умеешь проверять эффективность управления рисками — отдай это на аутсорс. Главное, чтобы было чёткое понимание, кто за что отвечает. Хорошим тоном считается, когда трудовые обязанности оговариваются в момент трудоустройства. В данном же случае управлением рисками фактически никто не занимался. Ну, и не стоит забывать, что у большинства руководителей есть вышестоящий руководитель. Если руководитель проекта несёт ответственность за проект в целом, то вышестоящий руководитель несёт ответственность за проекты всего подразделения в целом. Соответственно, то, что аналитик, неспособный руководить, занимается руководством проекта, да ещё и плохо делает свою работу аналитика, т.к. сам себе начальник — то это ошибка вышестоящего руководителя. Принцип Питера в действии. Увы, хороших руководителей ещё меньше, чем хороших программистов.
В организации без отдела тестирования из прошлой истории был предусмотрен механизм экстренного выкладывания патчей в случае обнаружения багов при боевом тестировании пользователями. Пользователь находит баг и отправляет заявку в первую линию поддержки. Первая линия поддержки, в случае если не может решить проблему самостоятельно, отправляет заявку руководителю проекта. Руководитель проекта убеждается, что это баг, а не незапланированные в графике желания пользователей, которые те пытаются продавить под видом бага, и отправляет заявку программисту. Как правило, для поддержки конкретного проекта закреплён единственный конкретный программист. Программист выкладывает исполняемый файл в заранее оговоренную папочку и пишет об этом в первую линию поддержки. Первая линия поддержки пишет системным администраторам. Администраторы выкладывают патч и отчитываются первой линии поддержки. Первая линия поддержки отчитывается программисту. Программист отчитывается пользователю. Пользователь подтверждает, что баг устранен. Как работает это «экстренное» выкладывание патча на практике? Частенько информация о баге приходит к программисту с запаздыванием в полдня. Человек из первой линии поддержки, закрепленный за данной заявкой, может отлучиться куда-нибудь на полчаса. Если программист не будет периодически спрашивать у первой линии поддержки, был ли выложен патч, то он скорее всего так и не узнает, а был ли он вообще выложен в этот день.
Как-то раз патч долго не выкладывался. Потом сообщили, что патч выложили. Но у пользователя баг не исчез. Подключились удалённо к пользователю, и выяснили, что патч всё же не выложили. Оказалось, что человек из первой линии поддержки предоставил неверную информацию админам. Перевыложили патч, всё заработало. И на кого тут можно переложить ответственность за то, что пользователь полдня не работал? Правильно, на программиста. Ну не на отдел же тестирования, которого нет, в самом деле. Ну и на себя напраслину возводить никто не будет, так что аналитик-руководитель, который не может перед отправкой новой версии программы проверить, что программист сделал именно то, что хотел аналитик, тут тоже ни при чём. А админы и первая линия поддержки вообще под чужой юрисдикцией, так что их крайними не сделаешь. Остаётся только программист. Что самое интересное, для «экстренного» выкладывания патча была даже реализована собственная программа, способная автоматически слать письма программисту, когда ему назначают исправление бага. Непонятно, что мешает хотя бы автоматически слать уведомления о выкладке патча программисту и пользователю, когда админы проставляют в этой программе пометку о выкладке патча. А вообще, хорошей практикой считается, когда патчи выкладываются нажатием одной кнопки. Например, с использованием тимсити. Изменение процесса выкладывания патча решает проблему и ослабляет риски, а поиск виноватых — нет.
Несмотря на абсурдность и аморальность такой тактики поведения, в некоторых случаях она оказывается действенной. Если руководитель не может повлиять на ситуацию (вышестоящее руководство не выделило средства, нет понимания как устроены процессы, которыми предстоит руководить и т.п.), то, устраивая неприятности тем, кто теоретически может повлиять на ситуацию, руководитель повышает шансы устранения проблемы. В одном магазине изымали все недостачи по товарам из зарплат грузчиков и кассиров. После этого работники магазина добровольно скинулись на видеокамеры и начали дежурить, просматривая видеозаписи. После того, как несколько покупателей-воров, регулярно обкрадывающих этот магазин, поймали за руку, недостачи существенно сократились. Несмотря на то, что положительный результат был достигнут, стоит отметить риски осуществления такой тактики поведения. Продавцы могли скинуться на камеры и пожертвовать личным временем, а могли устроиться на новую работу в магазин через дорогу. Эта особенность делает эту тактику крайне рискованной в IT. Я не рекомендую поступать подобным образом.
Я рекомендую вам этот алгоритм.
Для более глубокого знакомства с управлением рисками, рекомендую ознакомиться с книгой Тома ДеМарко и Тимоти Листера «Вальсируя с Медведями».
Может кому пригодится, вот ещё подборка книг для руководителей.
Все замечания по поводу опечаток, орфографических ошибок и тому подобного просьба отправлять личным сообщением. Но я не обещаю их исправить, потому что при написании статьи я не получаю вознаграждения (кроме опыта написания сочинений) и ничем не рискую (кроме рейтинга своей учётной записи). Тут, наверное, стоило бы плавно перейти к теме мотивации и самоидентификации, но, увы, на этом данная статья заканчивается. И, кстати, то что я не взял на себя обязательств по исправлению орфографических ошибок, не означает, что я обязательно не буду их исправлять — пишите, разберёмся.
Спасибо за внимание! :)
Тогда добро пожаловать под кат!
(В этой статье изложены мысли, навеянные творчеством Тома ДеМарко, и скорее всего статья будет неинтересна тем, кто уже знаком с его произведениями)
В 1988 году в городе Денвер было принято решение построить новый аэропорт вместо старого. Существующий на тот момент аэропорт не отвечал потребностям растущего города, и был непригоден для расширения. Был выделен бюджет, началось строительство. Но, к сожалению, проект не удалось завершить в срок. Причиной задержки оказалось не написанное вовремя программное обеспечение. Аэропорт был оборудован низкими узкими тоннелями, предназначенными для транспортировки багажа. Программное обеспечение должно было сканировать штрих-код багажа и направлять его в нужном направлении по сети тоннелей. Поскольку в силу незавершённости ПО доставка багажа оказалась невозможной, аэропорт простаивал вплоть до готовности ПО. Поскольку строительство аэропорта связано с огромными вложениями капитала, то весь этот капитал был заморожен, пока программисты второпях пытались играть в догонялки. А время – деньги. Упущенная выгода + убытки составили полмиллиарда долларов… СМИ уничтожила репутацию организацию-поставщика ПО, возложив всю вину на неё.
А теперь давайте представим, что менеджеры этого проекта потратили полдня своего драгоценного времени и занялись оценкой рисков, проведя мозговой штурм. Представим, что они собрались, и проанализировали, а какие убытки они понесут, если взлётная полоса или ПО не будут готовы вовремя, а также подумали, как можно сократить убытки в случае форс-мажора. Ей-богу, сеть крошечных туннелей — не единственный способ транспортировки багажа! Если бы было потрачена пара дополнительных миллионов долларов на постройку чуть более просторных туннелей, то можно было бы транспортировать багаж при помощи дешёвой рабочей силы или небольших грузовичков. Два миллиона — гораздо меньше, чем полмиллиарда. В конце концов, можно было даже не вкладываться в расширении туннелей, можно было бы использовать ездовых собак! Нанять кинолога, договориться с владельцем ближайшего питомника для беспризорных собак, и начать дрессировку. Если бы ПО было готово в срок, то в шаурмячных аэропорта цена хот-догов осталась бы неизменной, но вот в случае трудностей ездовые собаки смогли бы спасти положение. В любом случае, это хоть какая-то подстраховка. Но тут есть одно но. О таких вещах нужно задумываться заранее. Если в назначенный день сдачи проекта прибегает подрядчик с криками «шеф, всё пропало!», то тут уже поздно строить новые тоннели или дрессировать собак, потому что пока вы это доделаете, работы подрядчика наверняка приблизятся к логическому завершению.
Терминология
Когда вы закладываете в бюджет проекта потенциальные убытки от риска помноженные на вероятность риска, это называется сдерживанием риска. Риск либо наступит, либо нет. Если не наступит, то ваши денежки останутся при вас. Если наступит, то, возможно, дополнительных денег, которые вы заложили в бюджет, окажется недостаточно. Но если вы оцените все риски, и какая-то часть из них наступит, а какая-то нет, то вы, вероятно, уложитесь в бюджет.
Когда вы заранее тратите деньги, чтобы минимизировать убытки наступления риска, это называется ослаблением риска. Например, когда вы нанимаете кинолога для дрессировки собак. Неважно, наступит риск или нет, кинолог будет кушать и веселиться за ваш счёт.
Давайте изобразим соотношение ослабления и сдерживания рисков для строительства аэропорта.
Известно, что подобную программу другая команда программистов делала в два раза дольше. К тому же программисты постоянно жалуются, что им не удаётся догнать график, поэтому будем считать, что вероятность поспеть в срок — 50%. На самом деле, если вы знакомы с диаграммами рисков, то согласитесь, что вероятность наступления самого оптимального сценария из всех возможных равна нанопроценту, но мы, подобно руководителям стройки, немного завысим ожидания и будем считать, что вероятность успеха равна 50%. Как в одном бородатом анекдоте: либо получится, либо нет, поэтому 50%. В IT вообще в большинстве случаев временные и вероятностные оценки даются интуитивно и «с потолка». Итак, вероятность риска 1\2, цена — полмиллиарда, на сдерживание риска будем закладывать половину от полмиллиарда. Для ослабления риска потребуется несколько месячных зарплат кинолога, тонна собачьего корма, + зарплата уборщика, прибирающего за собаками, живущими в недостроенном аэропорту. Ну, или цена на более просторные тоннели — на ваш вкус. Примерно это будет выглядеть вот так:
Как видите, ослабления риска в конкретно данном случае выглядит гораздо выгоднее. Конечно, если риск не наступит, то вы потратите ресурсы, которые могли и не тратить. Но, с другой стороны, если наступит, а вы не подстраховались, то последствия будут катастрофическими. Это как пожалеть деньги на страховочный трос, когда вы собираетесь пройтись по канату. Ослабления риска гораздо дешевле, чем его сдерживание, и его выгода очевидна. Но давайте рассмотри обратную ситуацию — что если сдерживание риска гораздо дешевле, чем его ослабление? Значит ли это, что в таком случае нужно сдерживать риск? На самом деле, не всегда. Тут нам поможет философия воина.
Знакомьтесь, это Беззаботный Фермер. Он знает, что чем усерднее он будет поливать и пропалывать своё поле, тем более богатый он соберёт урожай. Картина мира Беззаботного фермера выглядит примерно так:
Чем больше постарался, тем больше получил. Зависимость экспоненциальная: со временем за те же усилия получаешь большее вознаграждение (растёт квалификация и положение в обществе, увеличивается пассивный доход и т.п.), до тех пор, пока не будет достигнут какой-то фиксированный потолок. Всё предсказуемо и просто.
А это Бесстрашный Воин. Воин может получить тысячу мелких ран, но продолжать твёрдо стоять на ногах; до тех пор, пока не получит фатальный удар. Во время противостояния двух сторон, каждая из сторон пытается по-максимуму реализовать фатальные риски противника. Утомить противника до смерти гораздо менее эффективно, чем нанести просчитанный удар в самое сердце. Для воина формула «больше усилий — больше вознаграждение» не работает. Он может лишиться всего из-за одной единственной ошибки. Для концепции рисков верны обе философии — и землевладельца, и воина — но концепция воина всё же ближе. Риск либо наступит, либо нет. Это либо приведёт к провалу проекта, либо нет. Со щитом или на щите. С другой стороны, мы живём не в древней Японии, и у нас не принято в любой непонятной ситуации рубить провинившимся головы налево и направо. Не каждый проваленный проект означает распад организации и конец карьеры руководителя. Из любой, казалось бы самой безнадёжной ситуации, можно постараться извлечь хоть какую-то пользу. Можно завершить проект с урезанным функционалом, сменить целевую аудиторию, использовать созданные наработки в следующем проекте, сделать выводы о причинах провала проекта и постараться не допустить подобного в будущем. От этого провал не перестанет быть провалом, но хотя бы какая-то часть ваших усилий окупится.
Примеры рисков при противостоянии двух сил
Следующим ходом белые ходят конём на e5. Если чёрные побьют ферзя, то последует мат:
7… С:d1 Чёрный слон рубит белого ферзя
8. C:f7+ Kp:e7 Белый слон, под прикрытием коня ставит шах чёрным. У чёрных единственный возможный ход королём на e7
9. K:d5# Второй конь на d5. Мат
Есть возможность срубить ферзя противника и позволить поставить себе шах, но если противник сможет реализовать появившиеся риски, то вы проиграете партию. Это — фатальный (или критический) риск для вашей партии.
Рассмотрим пример из командной интеллектуальной игры — доты, где каждая команда состоит из 5 человек. Чем больше локальных стычек выигрывает тот или иной игрок, тем сильнее становится его персонаж, и тем больше шансов у его команды выиграть партию. Однако даже если одна команда раз за разом побеждает, и, казалось бы, надежды уже нет, одна единственная ошибка игрока из доминирующей команды может означать проигрыш для всей команды. Если в шахматах цель — срубить короля, то в доте цель — срубить источник силы команды противника (мировое древо «белых» или магический ледяной трон «чёрных»). Бывает, что игрок рискует, нападая на более слабого игрока из команды противника, или же нападая вдвоём на одного. Риск заключается в том, что на самом деле это может быть западня, и игрока подстраховывают из засады. Если двое игроков попали в хорошо организованную засаду, то ближайший игрок скорее всего будет «убит» и на время до «воскрешения» окажется вне игры, а второй игрок может попытаться спасти его (с риском тоже оказаться на какое то время вне игры) или же бежать со всех ног, пока команда противника расправляется с первым игроком. Если второй игрок рискнет и тоже «погибнет», то команда останется в меньшинстве. После этого команда противника может начать полномасштабное наступление, и, пользуясь численным преимуществом, сломить оборону и уничтожить «источник силы» противника.
Это похоже на финальную битву из какого-нибудь боевика, когда один персонаж на протяжении всей драки получает множество люлей и вообще выглядит на фоне фаворита поединка полным слабаком, но в конце каким-то чудом отправляет таки противника в нокаут. Да, философия воина, она такая. Недостаточно просто кидать дальше, прыгать выше, бить сильнее и иметь больше опыта. Нужна мудрость и отвага, чтобы предвидеть возможные риски.
Давайте разберём, что проигравшая команда делала неправильно. Может быть им не стоило нападать и рисковать попасть в засаду? На самом деле, стоило. Риск и выгода ходят рука об руку. Окупившиеся риски приближают к победе. Кто не рискует, тот не пьёт шампанского. Другое дело, что рисковать надо с умом. В данном случае, второму игроку, когда он понял, что дело пахнет жареным, стоило спасать свою команду, а не своего напарника. С другой стороны, если вы вынуждены бросать товарища в беде — это явный признак того, что вы что-то делаете не так. В данном случае, следовало ослабить риск, предварительно проведя разведку. Да, это потребовало бы дополнительных затрат ресурсов и времени, но это существенно сокращает риски. Тем более, что команда доминировала и могла позволить себе потратить немного ресурсов на разведку. Видимо, ощущение скорой победы одурманило их, и они напрочь забыли о возможных рисках. Неуважение противника — это фатальная ошибка. Запомните, любые отношения между людьми строятся на взаимоуважении.
А теперь вернёмся к вопросу, а если сдерживание риска гораздо дешевле, чем его ослабление, то стоит ли в таком случае сдерживать риск? Напомню, что сдерживание риска = вероятность риска * убытки от наступления риска. Если риск наступит, то вам потребуется заплатить полную стоимость, которая может в разы превосходить сумму, заложенную в сдерживание риска. Если у вас нет возможности заплатить эту сумму, и это ознаменует провал проекта, то, на мой взгляд, лучше всё-таки заняться ослаблением риска. Если и ослабление риска не представляется возможным, то стоит хорошенько задуматься, а стоит ли вообще браться за этот проект. По-моему, разумнее получить половину от возможной прибыли, чем рисковать лишиться всего. Разумеется, вы не сможете проконтролировать все риски. Риск и выгода ходят рука об руку, поэтому иногда имеет смысл просто рискнуть. Вы не сможете гарантировать, что метеорит завтра не упадёт на ваш дом, но это не повод, чтобы не обзавестись собственным жильём. Может быть упадёт, а может быть и нет. Но дело того стоит! Но, с другой стороны, это не повод, чтобы не подстраховаться на случай, если всё-таки упадёт. Небольшая сумма денег в банке, достаточная для аренды жилья на несколько месяцев, вполне сможет сдержать риск замерзания от холода на улице.
В случае инновационных технологий, управление рисками становится довольно тонкой игрой. С одной стороны, работа с новой технологией сулит много рисков, но с другой, не рискнуть ей воспользоваться означает рисковать позволить конкурентам обойти вас. В данном случае, не рисковать — гораздо больший риск, чем рискнуть (звучит довольно замысловато, да?). Как я уже говорил, по-моему, разумнее получить половину от возможной прибыли, чем рисковать лишиться всего. Разумеется, тут нужна оценка конкретной ситуации. Уменьшение прибыли может гарантированно привести к выдавливанию вас с рынка конкурентами, если вы изначально не имели никаких козырей в рукаве. Составить какой-то универсальный алгоритм действий в данном случае не получится. Как говорил фельдмаршал Гельмут фон Мольтке, ни один план не выдерживает боевого столкновения с противником. Понимание текущей ситуации в тандеме с прогнозированием полезны на любой стадии проекта.
Обучение на собственных ошибках в процессе управления рисками
В ситуации с аэропортом в Денвере вся вина была возложена на конкретных исполнителей, хотя фактически ответственность и убытки легли на городской муниципалитет. Как управленцы могли бы понять, что они что-то сделали не так? Я заметил следующую закономерность: если маленькая неудача приводит к более большим и критическим последствиям, значит где то в управлении рисками допущен промах. Например, если из-за неготовности ПО простаивает весь аэропорт. Или, например, если из-за отключения электричества не работают сигнальные огни (для таких случаев можно запастись резервными генераторами). Если из-за ошибочного нажатия не той кнопки половина земного шара улетает в космос в виде осколков. А вот не надо кнопку от ядерного чемоданчика располагать рядом с кнопкой наливания кофе в кофейном автомате в холле, ага. Для управленца это выглядит так: какой-то исполнитель ошибся, нажал не ту кнопку, и теперь Земли нет, вся вина лежит на исполнителе. Ну а исполнителю кажется, что он ошибся совсем чуть-чуть, просто спросонья ударил не по той кнопке. Если есть ощущение незначительности ошибки, и оно звучит правдоподобно, то это сигнал о том, что управление рисками было проведено из рук вон плохо. Это, конечно, не оправдывает исполнителя, уничтожившего человечество. А вот не надо работать в конторах, в которых корпоративная политика предполагает обязательное наличие кнопки от ядерного чемоданчика в каждом кофейном автомате, ага. Ну, или хотя бы, не надо подходить к этим автоматам ближе, чем на 3 метра. Также можно попробовать добиться изменения корпоративной политики или обнести эти автоматы ограждениями. К сожалению, в большинстве компаний «инициатива наказуема», поэтому вам придётся устанавливать ограждения в своё личное время, за свои деньги, а также нести ответственность по всем рискам, связанным с этими ограждениями, даже если вы не управленец и не имеете полномочий и возможностей для управления этими рисками.
Возможен и другой случай — если риск лежит на поверхности, периодически приносит кучу проблем, но все его игнорируют, то исполнителю будет казаться, что ошибки неизбежны, как и проблемы, которые они приносят. Поскольку к проблемам будет выработано привыкание, не будет ощущения незначительности ошибок и значительности их последствий, а будет ощущение адовости происходящего.
Рассмотрим несколько историй из IT.
История 1. Подозрительный руководитель.
Жили-были две команды, трудящиеся в разных городах на благо одного стартапа. Первая команда состояла из продукт-овнера (замдиректора) и его помощника. Оба они совмещали функции руководителей, аналитиков и тестировщиков. Вторая команда состояла из нескольких программистов, тестировщика и тим-лидера. Занимались они автоматизированным сбором и переработкой информации, взятой из интернета, и публикацией её на своём сайте. Ну а поскольку источники, из которых собиралась информация, имели разный формат, и могли изменяться по прихоти разработчиков этих источников, то не всегда получалось корректно собрать с них информацию. С этой целью тестировщик круглыми сутками сравнивал информацию из источника с информацией на сайте проекта. Найдя ошибку, тестировщик заводит на доске соответствующую карточку с багом, программисты её исправляют, и в следующей версии программы подобная информация достаётся из источника корректно. А в другом городе другой тестировщик — помощник овнера — контролирует качество. Найдёт он давний, уже исправленный баг, но не заводит карточку, а докладывает продукт-овнеру. Потом программисты бодро рапортуют, что дескать, этот баг уже исправлен, мы только что передостали информацию для конкретно данного случая нашим самым свежим алгоритмом, и всё прошло без ошибок. Овнер не доверял программистам, и считал, что они покрывают себя и тестировщика, который не находит багов. К сожалению, в силу специфики проекта не было возможности передоставать из источника всю информацию за всё время с выходом каждой новой версии: во-первых, объёмы информации были велики, а, во-вторых, информация со временем теряла свою актуальность и ценность. В общем, спустя какое-то время, чтобы донести до удалённой команды серьёзность ситуации, овнер начал угрожать увольнением тестировщика и наказаниями для всей команды, а тим-лидер не стесняясь в выражениях за глаза бранил помощника овнера, и рабочая атмосфера стала не очень рабочей.
Можно ли было заранее спрогнозировать эту ситуацию? Это было бы непросто, но возможно. Достаточно было поочередно представить себя на месте каждого из участников процесса, учесть его должностные обязанности и представить, что именно он будет делать и с какими трудностями столкнётся. Овнер из другого города должен следить, чтобы удаленная команда не прохлаждалась и не бездельничала, а также задавать общее стратегическое направление проекта. Помощник должен ему в этом помогать. Команда должна работать. Естественно, при отсутствии полной прозрачности процесса, к овнеру в голову могут закрасться подозрения. Тем более, что полная прозрачность не могла быть достигнута, потому что ни овнер, ни его помощник никогда не занимались программированием, и соответственно не могли объективно оценить продуктивность удалённой команды. Соответственно, единственный возможный способ не допустить конфликта — сделать так, чтобы «надсмотрщики» не могли ни к чему придраться. Нужно было спрогнозировать этот риск и принять меры. Но даже когда риск наступил, тим-лидер и овнер не стали искать пути решения проблемы. Они стали искать виноватых. Проблему же частично решил программист, предложив на тестовой площадке удалять и перезаполнять данные за предыдущий месяц каждую неделю, чтобы помощник овнера искал ошибки в данных, полученных самым свежим алгоритмом. Основная проблема тут — отсутствие доверия и уважения между командами в разных городах, и эта проблема не была решена. Но теперь у овнера хотя бы стало меньше поводов для недовольства.
Мораль: решайте проблемы, а не перекладывайте ответственность. (Ответственность за весь проект в целом в любом случае лежит на руководителе проекта, подробнее об этом можно почитать в чёрной книге менеджера.) Под решением проблемы подразумевается анализ ситуации, поиск фундаментальной причины проблемы, оценка целесообразности по ослаблению риска для предотвращения повторения проблемы в будущем, поручение мероприятий по ослаблению риска подчинённым, контроль выполнения этих мероприятий. Разумеется, перед этим нужно раздать указания по устранению последствий уже наступившего риска.
История 2. Резкий переход на новую программу
Была одна программа для бухгалтерского учёта, условно назовём её программой А. Было решено написать новую программу Б, передающую данные программе А через базу данных. В новую программу Б вводились более детальные данные о процессе производства, нежели в старую программу А, затем в Б вычислялись необходимые данные и передавались в А. Пользователи должны были вводить данные в Б, а затем пользоваться старой программой А. Б использовалась не только для передачи данных в А, но и давала пользователям некоторые новые возможности. Разработчик новой программы Б не знал бизнес-логики программы А, и языка Delphi, на котором она была написана, поэтому уточнил у автора А какие данные и в какую таблицу передавать.
К сожалению, в этой организации не было отдела тестирования, а аналитик, знавший бизнес-логику, по совместительству была начальницей, и предпочитала перекладывать тестирование и частично аналитику на своих подчинённых — программистов. Если программист неверно понимал довольно абстрактные технические задания аналитика, то непроверенная аналитиком и неверно реализованная программа отправлялась к пользователю.
Чтобы у пользователей не возникло соблазна продолжать вводить данные в старой программе, было решено принудительно убрать у них такую возможность, резко переведя их на новую, недостаточно протестированную, программу. Руководительница дала задание автору старой программы внести в неё правки, запрещающие вводить данные, и тот оперативно выполнил задание. Не знаю, может быть, автор старой программы наивно полагал, что на этот раз тестирование было проведено. Может быть, сыграла роль вышеописанная проблема привыкания к неизбежности проблем. Как бы то ни было, про риски он не сказал. Ну а может быть, он подсознательно понимал, что ему, как единственному человеку, который в курсе бизнес-логики старой программы (если не считать руководителя-аналитика, разумеется), придётся проводить тестирование и он провалит сроки своей текущий задачи. Как бы то ни было, недопротестированная программа была принудительно поставлена пользователям. Ожидаемо, обнаружилось, что некоторые частные случаи не были учтены. Из-за этого работа пользователей несколько раз стопорилась на несколько часов, и в программу спешно вносились правки. Ответственность за это была возложена начальницей на разработчика новой программы.
Давайте разберём, какие ошибки были допущены в данном случае с точки зрения управления. Если в предыдущей истории тимлидер хотя бы теоретически мог предвидеть риски и ослаблять их, то у данной руководительницы, никогда не занимавшейся программированием, такой возможности не было. Поскольку руководительница должна была руководить IT-процессами, которых она не понимала, она постаралась переложить побольше ответственности на тех, кто их понимал, — на конечных исполнителей. Но сделала это в неявном виде. То есть после парочки неверно просчитанных рисков, программистам должна была стать понятной вполне чёткая и не скрываемая позиция начальницы: ты программист, делаешь всякие магические штуки, в которых я ничего не смыслю, ты в ответе за всё что происходит на проекте. Но напрямую задание изучить и начать управление рисками никому не выдавалось. Случается, что руководитель в каких-то вопросах некомпетентен, но это не беда, ведь у него есть подчинённые, которым можно поручить те или иные задачи. Не умеешь рисовать — поручи это дизайнеру, не умеешь писать сайты — поручи это программисту, не умеешь управлять рисками — поручи это старшему программисту, не умеешь проверять эффективность управления рисками — отдай это на аутсорс. Главное, чтобы было чёткое понимание, кто за что отвечает. Хорошим тоном считается, когда трудовые обязанности оговариваются в момент трудоустройства. В данном же случае управлением рисками фактически никто не занимался. Ну, и не стоит забывать, что у большинства руководителей есть вышестоящий руководитель. Если руководитель проекта несёт ответственность за проект в целом, то вышестоящий руководитель несёт ответственность за проекты всего подразделения в целом. Соответственно, то, что аналитик, неспособный руководить, занимается руководством проекта, да ещё и плохо делает свою работу аналитика, т.к. сам себе начальник — то это ошибка вышестоящего руководителя. Принцип Питера в действии. Увы, хороших руководителей ещё меньше, чем хороших программистов.
История 3. «Непрерывная интеграция» через «испорченный телефон»
В организации без отдела тестирования из прошлой истории был предусмотрен механизм экстренного выкладывания патчей в случае обнаружения багов при боевом тестировании пользователями. Пользователь находит баг и отправляет заявку в первую линию поддержки. Первая линия поддержки, в случае если не может решить проблему самостоятельно, отправляет заявку руководителю проекта. Руководитель проекта убеждается, что это баг, а не незапланированные в графике желания пользователей, которые те пытаются продавить под видом бага, и отправляет заявку программисту. Как правило, для поддержки конкретного проекта закреплён единственный конкретный программист. Программист выкладывает исполняемый файл в заранее оговоренную папочку и пишет об этом в первую линию поддержки. Первая линия поддержки пишет системным администраторам. Администраторы выкладывают патч и отчитываются первой линии поддержки. Первая линия поддержки отчитывается программисту. Программист отчитывается пользователю. Пользователь подтверждает, что баг устранен. Как работает это «экстренное» выкладывание патча на практике? Частенько информация о баге приходит к программисту с запаздыванием в полдня. Человек из первой линии поддержки, закрепленный за данной заявкой, может отлучиться куда-нибудь на полчаса. Если программист не будет периодически спрашивать у первой линии поддержки, был ли выложен патч, то он скорее всего так и не узнает, а был ли он вообще выложен в этот день.
Как-то раз патч долго не выкладывался. Потом сообщили, что патч выложили. Но у пользователя баг не исчез. Подключились удалённо к пользователю, и выяснили, что патч всё же не выложили. Оказалось, что человек из первой линии поддержки предоставил неверную информацию админам. Перевыложили патч, всё заработало. И на кого тут можно переложить ответственность за то, что пользователь полдня не работал? Правильно, на программиста. Ну не на отдел же тестирования, которого нет, в самом деле. Ну и на себя напраслину возводить никто не будет, так что аналитик-руководитель, который не может перед отправкой новой версии программы проверить, что программист сделал именно то, что хотел аналитик, тут тоже ни при чём. А админы и первая линия поддержки вообще под чужой юрисдикцией, так что их крайними не сделаешь. Остаётся только программист. Что самое интересное, для «экстренного» выкладывания патча была даже реализована собственная программа, способная автоматически слать письма программисту, когда ему назначают исправление бага. Непонятно, что мешает хотя бы автоматически слать уведомления о выкладке патча программисту и пользователю, когда админы проставляют в этой программе пометку о выкладке патча. А вообще, хорошей практикой считается, когда патчи выкладываются нажатием одной кнопки. Например, с использованием тимсити. Изменение процесса выкладывания патча решает проблему и ослабляет риски, а поиск виноватых — нет.
Рассмотрим несколько упрощенных алгоритмов поведения руководителей.
Алгоритм 1.
Несмотря на абсурдность и аморальность такой тактики поведения, в некоторых случаях она оказывается действенной. Если руководитель не может повлиять на ситуацию (вышестоящее руководство не выделило средства, нет понимания как устроены процессы, которыми предстоит руководить и т.п.), то, устраивая неприятности тем, кто теоретически может повлиять на ситуацию, руководитель повышает шансы устранения проблемы. В одном магазине изымали все недостачи по товарам из зарплат грузчиков и кассиров. После этого работники магазина добровольно скинулись на видеокамеры и начали дежурить, просматривая видеозаписи. После того, как несколько покупателей-воров, регулярно обкрадывающих этот магазин, поймали за руку, недостачи существенно сократились. Несмотря на то, что положительный результат был достигнут, стоит отметить риски осуществления такой тактики поведения. Продавцы могли скинуться на камеры и пожертвовать личным временем, а могли устроиться на новую работу в магазин через дорогу. Эта особенность делает эту тактику крайне рискованной в IT. Я не рекомендую поступать подобным образом.
Алгоритм 2.
Я рекомендую вам этот алгоритм.
Для более глубокого знакомства с управлением рисками, рекомендую ознакомиться с книгой Тома ДеМарко и Тимоти Листера «Вальсируя с Медведями».
Может кому пригодится, вот ещё подборка книг для руководителей.
Все замечания по поводу опечаток, орфографических ошибок и тому подобного просьба отправлять личным сообщением. Но я не обещаю их исправить, потому что при написании статьи я не получаю вознаграждения (кроме опыта написания сочинений) и ничем не рискую (кроме рейтинга своей учётной записи). Тут, наверное, стоило бы плавно перейти к теме мотивации и самоидентификации, но, увы, на этом данная статья заканчивается. И, кстати, то что я не взял на себя обязательств по исправлению орфографических ошибок, не означает, что я обязательно не буду их исправлять — пишите, разберёмся.
Спасибо за внимание! :)
topy
нипочём!