Управление рисками

Типовой сценарий управления рисками: узнать про управление рисками от начальства. Выписать всевозможные риски в табличку. Выписать "митигацию". И навсегда забыть. :)

Очевидно, что управление рисками - это не когда есть формальная табличка, а когда каждый вовлеченный человек знает эти риски, понимает их последствия и знает, что он должен делать для их предотвращения (a) или в случае их возникновения (б).

Как понять приоритеты клиентов?

 Если продукт действует на рынке сколько-либо долго, сколько-либо сложен и имеет сколько-либо значимую базу клиентов - то объем известных клиентских пожеланий в разы превышает возможности команды разработчиков. Пожелания превращаются в некий фон - все чего-то хотят, но что мы  должны делать? Что НА САМОМ ДЕЛЕ нужно клиентам?

Как мы это можем узнать? Забыв на время о сложностях опроса массовой аудитории, можем пойти самым элегантным способом - спросить. Но и тут не все просто.

Если вы пытаетесь понять приоритеты и задаете клиентам вопрос - "хотите ли вы X?", большинство ответят "было бы неплохо". Может и не особо нужно, но для них это ничего не стоит, так что почему бы и нет. Могут быть несколько человек, кто настолько озабочен какими-то острыми проблемами, что резко отреагирует на попытку двинуться в каком-либо ином направлении, кроме решения этих конкретных проблем - но в целом это не приближает нас к решению.

Решение - это вынудить клиента увидеть цену своих хотелок, выбирать разумно и обозначать приоритеты. Как это можно сделать -

1. ограничить длину списка. "Какие TOP5 вещей вы бы хотели добавить?" Будучи ограниченными в объеме, люди выберут наиболее важные для них. 
2. указать цену. "Сколько ваших клиентов готовы платить 2x за Y?" Недавно применил такой прием и спрос с 35% сократился до 15%
3. дать ложный выбор. "Вы бы хотели X или Y?" Оба кажутся нужными, но видя необходимость выбирать, клиент четко задает приоритет (1) и как правило объясняет причины (2).
4. потребовать детали. "Какие выгоды вы видите от X? Какие проблемы?" Если люди не готовы обсуждать какой-то вопрос, вероятно он им не сильно важен, они им не особо интересовались.

Станислав Протасов (Parallels) о Program Management

Станислав Протасов (Parallels) о Program Management:

Слушать пользователя, безусловно, надо. Это как в семейной жизни. Надо ли слушать жену? В принципе, надо. Но если все делать, как просит жена, скорее всего, она будет еще более недовольна. Ровно так же и с пользователем. Проблема в том, что невозможно слушать пользователя, если речь идет о новом продукте, которым он никогда не пользовался. Вот представьте, приходим к нему и спрашиваем:
― Хочешь ли ты, чтобы на нашей новой машине можно было разгоняться до 100 км\ч за 3,5 секунды?
― Да, ― отвечает он.
― Хочешь, чтобы все материалы были натуральные?
― Да!
― Хочешь, чтобы на дачу можно было отвезти блок кирпичей?
― Да!
В итоге мы делаем пикап с реактивным мотором, отделанный кристаллами Swarovski. И его никто не покупает. Потому что для фермера это дорого, а для того, кто предпочитает кристаллы Swarovski, это уродливо, к тому же состоятельные люди не хотят покупать те же машины, которые позиционируются для фермеров.
Слушать пользователя ― это нечто на грани науки и искусства. Людей, которые умеют слушать пользователей и доказали это на успешных продуктах, их очень мало. В России их практически нет, потому что у нас просто меньше людей в IT-индустрии. У нас приходится делать все на ощупь, из своих соображений, поэтому ошибок делается огромное количество.

...

Тут вопрос в здравом смысле. Надо уметь разделять wishful thinking, когда человек открывает чакры и вещает все, что ему приходит в голову, и реальную его нужду. Для этого в софтверных компаниях существуют продакт-менеджеры и програм-менеджеры, задача которых и заключается в том, чтоб определять «начинку» софта. 

Когда клиент хочет странного

Иногда приходят клиенты со странными запросами. Им очень нужна поддержка какой-то технологии. Чего-то сомнительного, непонятного, необщепринятого и маловостребованного. Зачем?

На свои вопросы мы слышим - это будущее, это стандарт, это must-have. Но смотрим шире и все это, скажем так, не вполне подтверждается. На самом деле клиент скорее всего кривит душой (хотя может и добросовестно заблуждается).

Просто многим нашим клиентам нашего продукта важно отличаться от других поставщиков подобных услуг. Кто-то пойдет по пути другой цены, другого уровня сервиса, других сервисов и т.д. А кто-то хочет отличаться уникальными предложениями - bleeding edge, innovation, top notch, быть вперед других. Разумеется, попытка быть впереди всех приводит людей в "серую зону" непроверенных технологий.

Что с этим делать? 

• В первую очередь даже странный запрос желательно проверять, рассматривать и интересоваться у более широких кругов. Быть может в ответ вы услышите "а кстати да..." и тогда появляется шанс "опередить паровоз". 
• Не менее важно посмотреть самим. Малоизвестная и маловостребованная технология сегодня, может и правда оказаться очень перспективной для вашего продукта. Если она помогает решать актуальные нам проблемы - берем и продвигаем, "толкаем паровоз". :)
• Посмотрите в корень проблемы. Данный конкретный запрос ("быть таким!") в целом для продукта не актуален, НО его обобщение ("быть другим!") вполне актуален. Клиенту на рынке важно отличаться от других - значит необходимы инструменты кастомизации и расширения функционала. В стандартную комплектацию не включим, а вот слоты расширения предоставим.
• Ну и если ничего из этого не подошло - время сказать "Извините, нет". Массовый продукт не должен сбиваться с выбранного курса без серьезной причины.

Say "No!"

Попалась статья с многообещающим названием Leadership: How to Say ‘No’ While Also Inspiring People и началом (цитата С.Джобса):

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.’

К концу впрочем автор свалился в благоглупости о том, как "правильно" говорить "No!":

• Yes! (без комментариев)
• Lets explore... (неплохо, давайте подумаем потом)
• What if? (давайте еще подумаем)

и по сути вывернул все наизнанку написав статью о том, как говорить "Да!".

Я бы с большим интересом посмотрел на Стива Джобса говорящего 1000 раз"Lets explore..." и "What if?..." вместо "No!"и с не меньшим интересом посмотрел на результаты.

Если лидер имел ввиду настоящий "Yes!" - то статья ни о чем. "Yes!" никак не отменяет необходимости разобраться дополнительно. Если же лидер имел ввиду "No!" - то оба дополнительных варианта банальная манипуляция и увертка, а вовсе не adult-adult разговор, который подается в статье как большое достижение.

Изначальный посыл Джобса именно о том, что надо говорить "No!". Простой и честный "No!". 1000 идей могут иметь какую-то гипотетическую пользу (совсем бесполезную идею тяжело найти в реальной жизни). И им всем надо будет сказать "No!" ради 1001й. Просто не надо "вилять". Объясните цели и отметайте идеи, которые им не соответствуют - вменяемые люди поймут.

Резкие изменения

Практически во всяком продукте есть необходимость развиваться как вширь, так и ввысь. "Вширь" - это добавление каких-то новых возможностей без изменения основных принципов продукта. Добавили еще один художественный фильтр в Picasa - это "вширь". Не каждый такое добавление и заметит. "Ввысь" - это существенное изменение принципов работы с пользователем.   Введение ribbon в MS Office 2007 - это было "ввысь".

Мотивация для развития "вширь" проста и очевидна - ежедневно продуктовая команда получает пачки запросов типа "а можно еще вот чтобы так...". Мотивация для изменения "ввысь" немного сложнее и сама она скорее характерна для retail продуктов, чем для "заказных":

• хотим выглядеть другими. Иногда нужно дистанцироваться от мрачного прошлого, иногда нужно подчеркнуть динамику. Обычно исходит от отдела маркетинга. 
• хотим лучше соответствовать своей (или еще не своей) аудитории. Пытаемся стать удобнее и тем привлечь правильную аудиторию. Может быть просто пытаемся следовать моде - в конце концов понятие удобства субъективно. :)
• просто пришлось в конце концов. Старые концепции становятся неадекватными новым задачам. Дальнейший рост без смены модели слишком труден.

По каким-бы причинам такое радикальное изменение не произошло - понравится оно не всем. Этих "не всех" может быть много. Можно их условно разделить на две группы

• Иррациональная. Те, кто уже привык и не хочет разбираться с новым. Оно им не нравится, просто потому, что оно другое. Скорее всего, не существует конечного списка исправлений, которые могли бы исправить ситуацию, не уничтожая новую модель полностью. Отсутствие такого списка позволяет точно идентифицировать таких клиентов.
• Рациональная. Кто-то использует продукт таким образом, что в новой модели ему объективно жизни нет или она очень трудна. Есть вполне конкретные сценарии и есть вполне конкретные проблемы, хотя выделить их за потоком возмущения может быть не просто. Почему-то интересы этой группы не учли при планировании изменений или учли и сознательно проигнорировали. Эти сценарии могут быть вполне вменяемыми, просто их не учли. Или совершенно странными и вы их даже вообразить не смогли.

А теперь интересный вопрос - что с ними делать и что они теперь будут делать с вами?

С иррациональной группой сделать ничего нельзя, кроме как предоставить старый интерфейс обратно (лучше, конечно, об этом с самого начала подумать). Но это не всегда возможно и не всегда разумно. Попытки сгладить отдельные углы ничего принципиально не изменят. Если не будет совместимого интерфейса, то многие уйдут. Чем легче уйти, тем больше уйдут. Иррациональность проявится также в том, что конкурентное решение не обязано быть лучше, или хотя бы более похожим на утерянное. Ниже отличная иллюстрация на примере уважаемого человека, недовольного Firefox 4:

Message #1:
... в продукт вносятся ЗАМЕТНЫЕ изменения. Не значимые, а именно заметные, бросающиеся в глаза. 
И все. Жопа.

Потому что если продукт был изначально хорошим, малые улучшения не будут заметны. Надо обязательно натянуть глаз на задницу, приделать к тапочкам ширинку и переиначить все элементы управления. Вот тогда это будет заметно, можно идти хвастаться новой разработкой.

А продукт не стал удобнее. Он стал кошмарно неудобным для "приверженных пользователей". И все ваши полезные новеллы утопают в кошмаре, которым вы их окружили. 

Хочется стукнуть по рукам и сказать:"ничего не трогай, гад!" 
...


Message #2:

... привыкнуть к этому новому уродству у меня не получилось. Поэтому я решил ... установить Гугл-Хром...Во-вторых, если уж и привыкать к новому интерфейсу, то лучше к совсем новому. Лису я не простил. 


Оставшиеся могут избегать апгрейда продолжительное время. При разумной политике поддержки старых версий, многие смогут привыкнуть или просто поддадутся "давлению прогресса".

Не следует, конечно, полагать, что иррациональное здесь синоним неправильного, просто всегда есть место субъективным симпатиям и привычкам. К примеру, мне когда-то очень нравилось ACDSee 2.9(?), а при апгрейде ее до ACDSee 3.2 мне она стала так неприятна, что у меня до сих пор где-то есть старый добрый дистрибутив. Обновленный продукт не нравился, категорически. Может быть он не был плохим, но мне не подходил совсем - тем более, что никаких собственных причин для апгрейда у меня не было.

C рациональной группой нужно много и тяжело работать. В первую очередь, надо разобраться с ранее неизвестными сценариями использования, выявить их потока часто совершенно неконструктивных жалоб, оценить широту использования и затем - или найти им место в новой модели или сознательно отказаться от конкретных сценариев и их аудитории. В ряде случаев может быть совершенно кривое и странное использование продукта (просто потому что раньше так было можно) - здесь можно убедить отказаться от неправильного варианта и порекомендовать более прямое решение.


Чему это нас научило? Урок вобщем-то простой - надо лучше изучать клиентскую базу, какой ее процент как использует продукт. Реальные сценарии могут радикально отличаться от тех, которые предполагались при разработке.

А как же урок не делать радикальных изменений? Так без необходимости их бы и не делали. :)

Проблемы и узкие места

Очень хочу порекомендовать книгу "Цель: процесс непрерывного совершенствования" Э. Голдратт. Написана в стиле художественного романа и этим похожа на "Роман об управлении проектами" ДеМарко, но ИМХО выше ДеМарко на голову - ситуация очень жизненная. Вечно опаздывающие проекты, "некогда точить пилу" и недостаточно времени на семью - ситуация в IT чуть менее, чем типовая. Как искать решение без привлечения нешних ресурсов должно быть интересно многим. Ко всем выводам читателя и главного героя подводят очень аккуратно - никаких натяжек. Язык перевода точно не хуже детективов и читается отлично.

Небольшой спойлер: Э.Голдрат - идеолог теории ограничений, согласно которой скорее всего есть лишь одно узкое место, в которое вы сейчас упираетесь. Предлагается найти это место, и подчинить все остальное задаче максимально эффективной работы в узком месте, не отвлекаясь на якобы эффективное расходование остальных ресурсов, которых все равно избыток.

Обсуждая эту книгу на кухне, прозвучала мысль, что где-то узкого места может и не быть. К примеру, у нас имела и имеет место ситуация, когда производительность системы неудовлетворительна, но узких мест в ней нет. Система тормозит однородно, если так можно сказать. Однако, если подумать, то узкое место выявить можно - хотя для этого необходимо перейти в другую плоскость анализа. Общая медленность системы есть результат ее архитектуры в какой-то степени и в пожалуй даже больше степени, результат повседневно применяемых практик программирования - они скорее определяются используемыми инструментами (библиотеками и фреймворками), чем собственно архитектурой. Очевидно, применяемые практики не удовлетворительны, однако изменить их, предложить новые, предложить политику перехода от старых практик к новым - на это банально нет времени. Пилить надо. Итак узкое место в производительности системы все-таки есть - это нехватка времени разработчиков. Возможно, что это узкое место не есть истинная причина - копая глубже, можно искать и найти причины нехватки времени. Для знакомства с методами анализа систем в поиске узких мест можно посмотреть другую книгу: Эли Шрагенхайм, Управленческие дилеммы. Теория ограничений в действии

Один из симпатичных мне выводов второй книги (перекликается с якокковскими мыслями о "крохоборах") - не слишком увлекайтесь оптимизацией расходов, в вырожденном случае они легко сводятся к нулю, обнуляя однако и прибыль

Счет-фактура

Адаптируя биллинг под российские нужды столкнулись с документом под названием "счет-фактура". Ряд существенных особенностей приводит к тому, что обычный invoice использовать для ее реализации никак не возможно. Какое-то время мы полагали, что счет-фактуру (как и автомат калашникова) от нас согли унаследовать китайцы и тогда затраты на разработку ее поддержки были бы оправданы - но китайцы и тут всех обхитрили и используют европейскую модель.

Итоговый рейтинг простоты ведения бизнеса -
#1 Американская модель отчетности
#2 Европейская модель отчетности
#3 Российская модель отчетности
А вот если мерить в сложности, то мы, безусловно, окажемся в лидерах :)

Слава Панкратов. Черная книга менеджера

Не возможно отмолчаться по поводу "Черной книги менеджера" Славы Панкратова :)

Многие отметили очень резкую форму изложения - бесконечные "лыбишься", "похуй", жутко менторский тон и непрерывное тыкание носом в лужу. Кто-то прорвался сквозь нее к сути, а кто-то не смог. Кому-то эта показная грубость настолько исказила картину, что я совершенно не понял каким образом они получили построили свои выводы из прочитанного.

Впрочем, мне используемый стиль особо резким не показался, хоть и пишется в предисловии, что специально старались. Это разговор себя завтрашнего с собой вчерашним, а по отношению к себе самому грубости быть не может. Скорее гипертрофированная искренность в попытке разбудить и донести некоторые простые истины.

Книга вобщем-то о том, как относиться к себе и к людям. К команде, к заказчику, к коллегам. Книга об Уважении и об Отвественности (именно с большой буквы У и большой буквы О). Как перестать кругом видеть проблемы и начать искать решения. И все вобщем-то на очень конкретных ситуациях - никаких абстракций и гипотез.

Крайне рекомендую. Всего 80 страниц сверхкрупным шрифтом, полчаса чтения - едва ли можно получить подобную информацию еще легче.

В завершение хочу поставить песню "Ты - человек" из советского к/ф "Приключения Электроника". Мне кажется она некоторым образом перекликается с содержанием книги. Приятного прослушивания. :)

iPod как убийца идей

Я никогда не ставлю себе фоновую музыку на работе. Еще лет девять назад заметил, что музыка невидимо и незаметно, но отвлекает от чего-то важного - код получается хуже, документы сумбурнее. Недавно однако заметил некоторый ущерб от подкастов, которые слушаю в машине. Оказывается я стал меньше думать о том, что надо сделать в течении дня по пути в офис и меньше стал анализировать итоги дня по дороге из офиса. Без сопутствующих размышлений и анализа деятельность становится более механической, появляется меньше идей, хуже понимание общей ситуации.

То, что казалось ненавязчивым обучением и эффективным использованием времени, оборачивается ощутимой проблемой.

Тестовое задание

А вот еще старая статья "Тестовое задание" - по правде сказать, я ее не писал. Добрые люди из HR собрали набор моих (и не только моих) разрозненных ответов и привели к структурированном целостному виду. Получилась очень конкретная шпаргалка на тему "Как очень понравиться компании Parallels". У студентов это называется "бомба" - бомбой это и было бы, если бы опубликовали.

Разумеется, мы тот текст публиковать не стали и отредактировали его в другом ключе - более полезном и для нас, и для соискателей. Превратили статью из анаболического стероида в полезный витаминчик.

Откуда вообще возникает эта проблема с тестовыми заданиями? Самый странный факт в моей жизни - 90% соискателей-программистов  вообще не воспринимает тестовое задание всерьез. И реализуют его по принципу "ну оно же делает то, что вы просили?". В большинстве случаев действительно делает (хотя иногда бывает, что присылают и нерабочие варианты). Однако затем проверяющий начинается "придираться" к коду, к алгоритмам, к методам и это многих возмущает - "вы же не ставили таких требований!".

Ну конечно же не ставили. :) Единственная цель, с которой людям дается тестовое задание, это увидеть, какой код они оставят в проекте. И если код понравится понравится, то добро пожаловать. Это как портфолио у дизайнера и относиться к нему надо соответственно.

Конечно, оценка ТЗ остается субъективной - но так и должно быть. Небольшие расхождения - это повод к интересной дискуссии, где обе стороны остаются довольны друг другом. Ну а если никакого согласия нет, то вообще не важно, кто прав "на самом деле". Ведь если вы не приняли их точку зрения, а они вашу - то стоит ли вам вообще работать вместе? Вот вы друг друга и протестировали. :)

Собеседование наоборот

Однажды я позвонил соискателю, но не смог его спросить практически не о чем. Все отведенное время соискатель засыпал меня вопросами сам. Через 40 минут у меня было стойкое ощущение, что  у меня проводе очень перспективный кандидат - из вопросов следовало хорошее знание индустрии в целом и сходство представлений о правильной организации работы с нашими собственными. После пары последующих собеседований человека наняли и в настоящее время я считаю его очень хорошим приобретением для компании.

И мне кажется результат более чем закономерен - 

1) чтобы задать правильный вопрос надо знать половину ответа, так? а значит по вопросам можно очень хорошо понять, что человек уже знает.

2) вопросы частью готовятся заранее, а частью возникают на ходу. а значит по вопросам можно оценивать и степень предварительной подготовки (а значит насколько человек серьезно относится к делу), и умение управлять диалогом (а значит умению фокусироваться, выделять приоритеты и т.п.)

Наверное, имеет смысл применить такой отбор более широко. 

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

Буржуи, похоже, применяют этот подход шире - у них распространена практика коротких встреч соискателя с потенциальным работодателем не в форме стандартного интервью, а скорее в беседы за ланчем -  пораспрашивать о компании, при случае показать портфолио или резюме, а в итоге - произвести впечатление и завязать нужные связи (networking то есть). Кажется разумным.

Начнем пожалуй

Старая статья "Что же такое Program Manager?" - мы тогда набирали интернов на роль Program Manager'а и хотели объяснить, о чем же эта работа. Было очень трудно выбирать среди студентов - мы все любим поспрашивать об опыте, о примерах из жизни - у этих же ребят жизнь только началась и значительную часть себя они еще может и сами не поняли, не то что успели где-то продемонстрировать. И конечно же они никогда раньше не работали в этой роли. Пришлось соверщенно новую схему собеседования изобретать - намного сложнее задача оказалась, чем собеседовать программистов и IT менеджеров. Впрочем, все получилось и в итоге у меня были целых три кандидата категории "A". Выбрать надо было одного и предпочли того, с которым уже как-то работали раньше - не скрою, повлияло то, что риски хотелось как-то сократить. Вакансия одна и другой в ближайшее время не предвиделось. В выборе не ошиблись и это радует.

Что до остальных - уверен у них все получится. Категорию "А" я там так просто не присваивал. :)

Что это и о чем

Когда то на просторах ЖЖ несколько молодых тимлидов (без англицизмов никуда - но обещаю не увлекаться) активно писали о наболевшем. Традиционно - их окружади идиоты-коллеги, ламеры-клиенты и знали они все лучше всех (и уж конечно лучше своего начальства). :)

Время шло - писать становилось как-то некогда, да и в каком-то смысле сложно - и начальник, и коллеги, и команда - все читали друг друга. Привычные посты на тему "WTF?" стали как-то неуместны - уж если "wtf" случался, то о нем надо было не в жежешке писать, а с конкретными людьми работать и решать. Иначе выходило как-то безотвественно. Так вся письменная деятельность потихонечку и умерла, свелась к совершенно нейтральным и абсолютно нерабочим сообщениям.

Прошло года 4 кажется. И вроде накопились какие-то материалы, какие-то мысли, которые можно писать с чуть более высокой колокольни, чем тогда. Посмотрим, что получится.