Архив рубрики: управление проектами

Персики, лимоны, рынок вакансий в IT и как все это связано

Эта статья подготовлена для блогов журнала PCWeek.
В 2001 году Джордж Акерлофа получил нобелевскую премию по экономике за анализ рынков с ассиметричной информацией. Ходит байка, что когда он впервые отправил статью про персики и лимоны в экономический журнал, ее отклонили, посоветовав такие статьи отправлять в журналы по садоводству. Что же за понятия персиков и лимонов ввел Акерлофа, и какое отношение они имеют к рынкам с ассиметричной информацией? И вообще, причем здесь вакансии в IT? Вот об этом и предлагаю поговорить.

Одним из очень ярких примеров рынка персиков и лимонов является рынок подержанных автомобилей. Под персиком на нем понимается хороший автомобиль, под лимоном - автомобиль, только выглядящий как хороший, но таковым не являющийся. Покупатель, в отличие от продавца, не владеет информацией о том, какой автомобиль перед ним. Это и есть рынок с ассиметричной информацией. Из-за такой асимметрии продавец персика не может запросить цену выше, чем стоящий рядом продавец лимона. Ведь в этом случае покупатель купит лимон, поскольку при осмотре персик и лимон выглядят одинаково.
Теперь от рынка подержанных автомобилей перейдем к вакансиям в IT. На рынке труда ситуация очень похожа. Кандидатов можно условно разделить  на две группы: лимоны (вроде что-то и умеют, но работать и учиться особо не хотят) и персики (может, не всегда много знают, но много и продуктивно работают, хотят обучаться, расти). Понятно, что кандидаты, как правило, адекватно оценивают себя, а вот рекрутеры не всегда. Отличить лимон от персика, особенно, когда лимон уже прошел несколько собеседований, а персик пришел только на первое-второе, практически невозможно. Ситуация усугубляется еще тем, что рекрутер, возможно, и хочет персик, но, имея «лимит по цене», готов взять и лимон, лишь бы закрыть вакансию. А выбирая лимон, он еще и деньги «сэкономит». Сэкономит в кавычках, так как после покупки лимона компании в достаточно краткосрочной перспективе придется его увольнять, открывать вакансию и снова начинать круг поиска.
Давайте взглянем на эту ситуацию с точки зрения теории игр. Рассмотрим атомарную игру, в которой рекрутер предлагает оффер, а кандидат принимает или отклоняет его. Для простоты, пусть лимон приносит компании 50 единиц прибыли, а персик 200. В случае, когда лимон и персик не знают своей стоимости, выставив цену в 125 единиц, набирая одинаковое количество лимонов и персиков, на каждом лимоне мы будем терять 75 единиц, а на персике получать 75 дополнительных. Глядя на существующий рынок труда, мало кто согласится, что количество лимонов и персиков на нем одинаковое. Получается, что даже в условии симметрии информации ( когда ни рекрутер, ни кандидат не знают, кто он - персик или лимон) мы остаемся на нуле только при одинаковом количестве лимонов и персиков на рынке. Но, если цена всех будет одинакова, то персики с рынка будут вымываться: зачем учиться, если все равно будешь стоить 125?
Ситуация становится еще хуже, когда информация асимметрична. Персик, получив предложение в 125, от него откажется, ведь он знает, что его цена 200. А вот лимон, услышав 125, согласится, ведь он-то знает, что его красная цена 50. К чему же это приводит:
  1.      . Лимоны переоценены
  2.      . Персики недооценивают, становиться ими нет резона и…
  3.      . Рынок персиков исчезает

Собственно за эти выводы Джордж Акерлофа и получил нобелевскую премию по экономике.
Как же можно предотвратить исчезновение рынка персиков? Самое главное - это не соглашаться на лимон, если вам нужен персик. Очень показательный пример описан в одном из номеров  Harvard Business Review Россия в заметке "Во что обойдутся низкие зарплаты", где сравнивается стратегия Wal-Mart, проявляющаяся, в частности, в жестком ограничении зарплат сотрудников, и его прямого конкурента Costco, у которого относительные затраты на персонал существенно выше, а число сотрудников во столько же раз меньше. Показано, что в долгосрочной перспективе Costco получает надежный и эффективный персонал, а также низкую текучесть кадров. Ведь наличие талантов в организации в конечном итоге намного важнее размеров их оплаты труда.
Внимательный читатель задаст вопрос: «А как же отличить персик, ведь у нас рынок с ассиметричной информацией?» А вот это второй шаг. Должен быть изменен подход к рекрутингу IT-персонала. Сейчас на первом собеседовании соискателя на вакансию встречает, как правило, молодая девочка без существенного опыта за плечами. Она задает типовые вопросы и предлагает типовую ставку. Как на это реагируют лимоны и персики, можно посмотреть в описании игры выше. Да, это дорого - проводить первичные собеседования высококвалифицированным, опытным сотрудником. Но здесь возникает вопрос: «А не дорого ли нам обходится регулярный найм лимонов, и что мы будем делать, когда рынок персиков окончательно схлопнется?»

О KPI и мотивации

Эта статья подготовлена для блогов журнала PCWeek.

«Наиболее важные факторы, необходимые для управления любой организацией, как правило, неизвестны и количественно неопределимы»
Э. Деминг, "Выход из кризиса"
Открывая новый проект, запуская изменения в существующем процессе, мы придумываем метрики и задаем KPI. И, как правило, за достижение этих KPI назначаются ответственные, которые получат бонусы или будут наказаны за несоответствие реальности целевым индикаторам. Предполагается, что наличие таких показателей должно стимулировать исполнителей. Но как на самом деле все это работает? В большинстве случаев – странно.

Если бизнесом организации не является разработка программного обеспечения или аутсорсинг IT-услуг, то практически невозможно привязать показатели подразделений IT к ее экономическим результатам. Например, бизнес запускает новый вид услуг, IT внедряет соответствующую инфраструктуру, но прибыль запущенная услуга не приносит. Кто виноват? IT или экономическая ситуация на рынке? Или другой пример: IT повысило надежность предоставляемых бизнесу сервисов с 95% до 98%. Бизнес получил прибыль на 10% больше по сравнению с предыдущим годом. Это достижение IT или особенность все той же экономической ситуации? В результате, появляются KPI, не имеющие никакого отношения к полезности IT для бизнеса. Сотрудники не понимают, зачем требуются такие показатели. А все то, что люди не понимают, или вообще не делается, или делается спустя рукава. А раз делается плохо, то вводится материальная мотивация. И тут возникает вторая проблема – локальные экстремумы.
В IT, в связи с производственными особенностями, работают умные люди. Поэтому, когда необходимость KPI не понятна, а за несоответствие показателю будут наказывать рублем (да, неполучение премии - это наказание), сотрудники начинают искать локальный экстремум. В нем KPI должен быть выполнен, а вот работы на это должно быть затрачено по минимуму. Как это проявляется? Допустим, мы ставим KPI программистам по количеству багов. В этом случае обнаружение каждой ошибки в тестировании будет выливаться в целое представление. «Нет, это не ошибка! Нет, это не моя ошибка, а ошибка внешней библиотеки!» А через какое-то время может выясниться, что разработчик договорился с тестировщиком, и тот сообщает об обнаруженных ошибках неофициально. В итоге в багтрекере багов нет, а в продукте есть. Конечно, такие KPI дают эффект на первом этапе, но потом дела будут идти все хуже и хуже, так как все будут стремиться обмануть систему, чтобы соответствовать именно требуемому показателю, пусть даже в ущерб компании. Хуже всего то, что менеджеры, в надежде избежать такой ситуации, добавляют третью проблему – избыточную сложность.
«Ах, вы научились обманывать KPI? Давайте добавим еще вот эту, а потом вот эту метрики». И тогда мало того, что начинается «гонка щита и меча» между метриками и теми, кто пытается их обмануть, так еще и на поддержание этой системы тратятся огромные ресурсы. Бывает, что это заканчивается коллапсом системы, так как через достаточно небольшое время уже никто не понимает, что считается, как считается, как проверяется.
Что же делать? Во-первых, не применять KPI, не понятные команде. Необходимо создавать систему, в которой люди могут делать свою работу. Ведь мы их приглашали на работу именно потому, что они могут и, самое главное, хотят работать, развиваться, расти. Во-вторых, не нужно придумывать метрику под KPI. Должна быть поставлена некая цель и подобраны практики, позволяющие ее достичь. Должна быть выбрана максимально простая и прозрачная метрика, позволяющая измерить эффективность применения практики. Должны быть назначены понятные и достижимые целевые значения метрики. И только тогда все это соберется в KPI. В-третьих, KPI должен быть принят исполнителями, они должны понимать, как его выполнение улучшит именно их работу.
Если эти пункты кажутся слишком сложными, то есть путь проще: открываем http://kpilibrary.com, вводим ключевое слово и берем верхний KPI из результатов поиска. На сайте десятки тысяч KPI, почему бы и не взять из них первый попавшийся?

Как изменить поведение сотрудников

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

Человеческий мозг принято делить на творческое (правое) и рациональное (левое) полушария. Но кроме творческого и рационального начала, правое полушарие отвечает за потребности, а левое -за стратегии по их удовлетворению. То есть, именно правое полушарие получает сигнал от желудка и вырабатывает потребность : «Хочу есть». Причем потребности эти могут быть как физиологические, так и расположенные выше по пирамиде Маслоу. Именно это полушарие сообщает нам о потребности в безопасности, быть признанным и т.д. Все эти потребности распределяются правым полушарием по приоритетам, после чего в процесс вступает левое полушарие. За работу со стратегиями отвечают лобные и теменные доли. Лобные - это то, что принято называть разумом. Мы прибегаем к нему, когда, попадая в новую ситуацию, придумываем новые стратегии. Но в большинстве случаев лобные доли ленятся, и работу на себя берет теменная часть мозга. А она отвечает за использование уже имеющихся стратегий. И, так же, как правое полушарие расставляет приоритеты потребностям, левое полушарие приоритезирует стратегии: «В прошлый раз я опоздал на работу и сказал, что попал в пробку. Меня не ругали, значит, эту стратегию с придумыванием отговорок можно применить и в следующий раз».
Исходя из всего выше сказанного, для того, чтобы изменить поведение, обусловленное стратегиями, достаточно понизить приоритет стратегий контрпродуктивных и повысить приоритет стратегий продуктивных. Воспользуемся любимым инструментом многих менеджеров - матрицей два на два - и проведем с ее помощью группировку всех методов, позволяющих влиять на приоритет стратегий:
Зеленым цветом выделены так называемые «добрые методы воздействия», они нацелены на то, чтобы осуществление полезного деяния человеком получало подкрепление в виде положительных эмоций. «Злые методы», выделенные на рисунке красным, заключаются в намеренном применении страданий с целью изменить нежелательное поведение.  По большому счету, «злые методы» - это менеджерские методы. Добрые – лидерские. Видимо, благодаря работам Беррес Фредерик Скиннера и предложенной им теории оперантного научения, и закрепилась слава именно лидерских подходов. Беррес одним из первых выдвинул тезис, что стабильные изменения поведения достигаются только с помощью положительных стимулов. Но нужно понимать, что лидерские методы работают не всегда. Бывают ситуации, когда необходимо избавиться от нежелательного поведения, в которых приходится применять злые-менеджерские методы. Например, сотрудник постоянно опаздывает на работу, не сообщает вовремя о проблемах, критикует всю команду, обесценивает чужую работу и т.д. Во всех этих случаях нет полезного поведения, которое необходимо подкреплять. А есть деструктивное, которое необходимо искоренять.
К злым методам относят:
  1. Угасание
  2. Отрицательное подкрепление
  3. Ограничение
  4. Наказание

Угасаниебазируется на отказе человеку в реакции. Поведение, не получающее ни положительного, ни отрицательного подкрепления, со временем угаснет. Особенно этот метод хорошо работает с поведением, имеющим словесное выражение. К примеру, если на постоянную критику команды одним из ее членов никто не будет реагировать, то, не получая подкрепления, эта стратегия сойдет на нет. Ведь человек критикует не просто так, а потому, что у него есть потребность, например, в получении статуса. И он эту потребность пытался удовлетворить, «опуская» всех остальных. Нет реакции - нет удовлетворения потребности, стратегия откладывается, как не приносящая результата.
Отрицательное подкрепление заключается в любом неприятном событии или стимуле, пусть даже весьма слабом, который следует немедленно после действия или во время действия. В отличие от наказания, его нельзя применить через час, день, неделю. Достаточно часто отрицательное подкрепление может быть минимальным. Опоздал сотрудник на работу? В большинстве случаев, чтобы поведение изменилось, может быть достаточно хмурого взгляда или раздраженного приветствия от человека, которого опаздывающий уважает. Не нужно забывать, что у того же опоздания могут быть и объективные причины, например, заболел член семьи, отводящий ребенка в детский сад, и сейчас у сотрудника нет возможности прийти вовремя. Как только внешний фактор исчезнет, без всяких воздействий со стороны руководителя прекратится и неконструктивное поведение. Нужно просто разобраться в мотивах. Кстати, если опоздание обусловлено желанием вечером подольше почитать фейсбучек, то отрицательное подкрепление не сработает по той простой причине, что фейсбучек был вчера, а отрицательное подкрепление -сегодня.
Ограничение – один из основных менеджерских инструментов. Он заключается в невозможности осуществить нежелательную стратегию. Сотрудник пытается сидеть во время ежедневного стендапа? Проводите митинг в комнате, где сидеть вообще не на чем. Сотрудник постоянно критикует применяемые в команде процессы? Введите ограничение, что критиковать процессы можно только на ретроспективе. Увольнение сотрудника - это ведь тоже ограничение. У него больше нет возможности вести себя неправильно, по крайней мере, в рамках данной компании.
Наказание. Если предыдущий метод был основным, то этот является излюбленным методом очень многих руководителей. Когда поведение сотрудника неправильное, мы в первую очередь думаем о наказании: ругаем, снижаем зарплату, налагаем штрафы. К сожалению, этот метод работает очень плохо. Вроде и наказали за неконструктивное поведение, а оно возникает снова. Большинство руководителей просто пытается увеличить наказание. Чтобы наказание было действенным, должно сойтись много факторов:
  • Поведение должно находиться под контролем получающего наказание. Если человек вынужден отводить ребенка в детский сад за заболевшего члена семьи, то, даже наказывая его штрафом, мы не изменим поведение: сад от нашего штрафа раньше не откроется, да и заболевший быстрее не выздоровеет.
  • Сотруднику должно быть понятно, за какое поведение он не получит санкций. Если он не понимает, на что менять поведение, то он его и не изменит. Всегда нужно объяснять, что это наказание, например, не за несданный вовремя отчет. Наказание за то, что руководитель узнал о проблеме в момент, когда отчет понадобился, а не заранее, когда можно было поручить эту работу другому или помочь в работе над отчетом другим способом.
  • Наказания применяются намного реже, чем поощрения. Да, это опять отсылка к работам Скиннера: в долгосрочной перспективе работают только положительные методы.
  • Наказание воспринимается как справедливое. Это один из самых тонких моментов, но и один из самых важных. Если наказание воспринимается неадекватно легким, то на изменение поведения оно не повлияет. Если неадекватно тяжелым, то может и повлияет, но вызовет озлобленность, желание отомстить, приведет к конфликту и т.д.
  • Страх перед будущим наказанием намного больше немедленных выгод от негативного поведения. Очень часто руководители грешат тем, что сразу после нежелательного поведения на волне эмоций наказывают строго, но если денек «пошифроваться», то наказания не будет или оно будет незначительным. Это провоцирует сотрудника скрываться, отключать телефон и вообще вести себя как маленький ребенок, закрывающий глаза, чтобы не видеть буку, вместо того, чтобы решать проблему прямо сейчас. Чем позже руководитель применяет наказание сотрудника , тем оно должно быть сильнее, чтобы у наказываемого не было стимула скрывать возникающие проблемы с целью смягчения наказания.
Подводя итоги, остается только пожелать, чтобы нам всем приходилось как можно реже применять все то, что описывается в этой статье, и как можно чаще то, что на схеме находится в зеленых четвертях. Но об этом в другой раз.

Ветки (Branch) и слияния (Merge) в TFS


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

Механизм создания веток позволяет некоторую папку в хранилище кода скопировать в другую папку хранилища как есть. Т.е. на момент создания ветки (branch) мы получим две папки абсолютно идентичные друг-другу и отличающиеся только названием. Для создания ветки, достаточно на любой папке открыть контекстное меню  и выбрать:
Ветки всегда создаются на сервере, т.е. после выбора этого пункта и ввода имени папки в которую необходимо делать ветку, на сервере TFS будет произведено копирование всех файлов с папки источника в папку приемник. Кстати, TFS запоминает все такие ветки и даже может их визуализировать. Первая картинка к этой статье, как раз показывает ветки одного из наших проектов. Правда визуализация немного хромает, если преобразовать ветку в папку. Но об этом в другой раз.
Зачем могут быть нужны две папки с абсолютно одинаковым содержимым? На самом деле, все просто. Вы можете сколько угодно изголяться над одной из веток и потом просто ее удалить. Во второй ветке у вас останется исходный код. Согласитесь неплохой способ проводить эксперименты. Еще одна замечательная возможность предоставляемая TFS заключается в слиянии (merge) веток. Если две папки связаны между собой в результате Branche, то выбрав одну из них, мы все изменения можем слить в другую (на картинке выше пункт merge):
В открывшемся окне мы можем выбрать в какую из веток выполнить слияние и указать, перенести все различия между ветками или можем выбрать конкретные наборы изменений которые необходимо перенести. Хранилище само определяет в чем заключается разница файлов хранящихся в ветках и вносит на машине пользователя необходимые изменения в локальные файлы. Т.к. в отличии от Brunch проходящего на сервере, Merge происходит на локальной машине и его нужно возвращать на сервер в рамках набора изменений. Это связано с тем, что при внесении изменений параллельно в двух ветках, при их слиянии могут возникнуть сложности с автоматическим объединением изменений в разных ветках одного и того же файла. И эти изменения придется выверять и подтверждать вручную.
Теперь о том, как мы эти ветки используем у себя.
Во-первых, у нас есть папка с набором базовых компонентов (Core). Эта папка размножается ветками в корневые папки всех крупных проектов. Делается это для того, чтобы при необходимости внести изменения (бывает очень редко, но бывает) в базовые компоненты, можно было эти изменения обкатать на том проекте которому они нужны. Слить эти изменения в исходную ветку, убедиться что в ней все хорошо и потом из коревой ветки слить изменения с веткой Core в остальных проектах. Т.к. во всех проектах настроены автоматические билды, то если в результате слияния изменений из Core в ветки проектов что-то пойдет не так, все разработчики узнают об этом сразу. Схематически это все выглядит вот так (картинки кликабельны):
Если еще не запутал, то во-вторых, ветки у нас применяются для разделения проекта. Разработка нового функционала ведется в основной папке проекта. Ближе к концу спринта, когда основной функционал реализован, все изменения перемещаются в заранее подготовленную ветку Prerelease. В этой ветке идет стабилизация версии перед релизом. После того, как QA дает отмашку на релиз, все изменения перемещаются в ветку Release и разворачиваются в эксплуатацию. Благодаря этим трем веткам всегда есть возможность спокойно проводить стабилизацию перед релизом, не опасаясь, того, что кто-то начнет писать новый функционал и сломает тот код, который в рамках стабилизации уже был подвергнут регрессу. Также, наличие ветки с кодом идентичным развернутому в Operation позволяет править ошибки обнаруженные в процессе эксплуатации именно в том коде, который эксплуатируется. И даже если в ветке разработки поправили модель данных или сломали вообще все, есть возможность внести минимальные изменения в стабильный код и развернуть его после проверки в эксплуатацию. Выглядит это примерно так:
Ну и объединяя две предыдущие картинки, схема веток Core и проектов будет выглядеть так:
На сегодня думаю хватит, а в следующий раз я тогда покажу как ветки связаны с тегами рабочих элементов и что приходится делать для некоторых из них.

О тегах в TFS


С появлением этой замечательной штуки в TFS убедить себя добавить полей к Work Item-ам стало значительно труднее. Под катом небольшая история о том, какие теги мы используем и для чего.

Сразу скажу, что тегов мы используем всего 7. Помечаются тегами только баги и PBI. Причем некоторые теги привязываются только к PBI, а некоторые только к Bug. Поехали.

NotReady
Этим тегом помечаются только PBI и только в основном бэклоге. Этот тег сообщает о недостаточной подготовке PBI. Как правило, это пометка о необходимости обсудить его с заказчиком.

added
Это тег тоже только для PBI, но уже в спринте. Им помечаются требования добавленные в спринт заказчиком после его начала, как правило с аргументацией: "А!!! Мы все умрем!!! Срочно!!!". Сразу оговорюсь, что ситуация хоть и плановая, но не массовая. По статистике за последние 40 спринтов, на 13-14 запланированных в начале спринта Effort приходится 1 Effort добавленный в итерации.

td
Этим тегом помечаются PBI которые можно отнести к классу технический долг. Т.е. в силу тех или иных причин был реализован функционал, пользователя он устраивает, но остались некоторые шероховатости в реализации. Например, был реализован показ пользователей некоторой системы, но т.к. список большой, он грузиться долго. Функционал есть и он работает, но в бэклог помещается PBI с указанным тегом и содержанием: переделать на постраничный вид.

unscheduled
Этот тег очень похож на added, и также вешается на PBI которые попали в итерацию после планирования, но, есть и отличие. Если в конце спринта кончились запланированные требования и закрыты все баги, а время еще есть, то вместо разброда и шатания, берется в спринт еще несколько PBI и они помечаются этим тегом. Позволяет проанализировать результативность планирования спринта. Правда, такое бывает очень редко, но если что, то такой тег у нас есть.

release
Этим тегом помечаются в основном баги, и он говорит об обнаружении ошибки в эксплуатации. У этого бага максимальный приоритет, он правиться в специальной ветке и после исправления и тестирования, исправление разворачивается на боевые сервера. Очень редко это тег ставиться на PBI, но это как правило небольшие изменения и в этом случае он идет еще и с тегом added.

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

prerelease
Применяется только к багам и говорит о том, что исправлять его нужно в ветке стабилизации перед релизом. Появляется только в конце спринта, когда вся разработка нового функционала завершена и идет именно стабилизация.

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

Scrum доска


Этот пост, попытка собрать в кучу мысли о Scrum доске. Поводом послужил вопрос нашей новой сотрудницы. Ей конечно ответил у реальной доски, ну а здесь, на будущее.
Под катом будет:
1. Почему нам не подошла доска из TFS
2. С чего все начиналось
3. Как выглядит сейчас

В проекте TFS предназначенном для Scrum, есть доска. Выглядит она прикольно и имеет вот такой вид (если что, картинки кликабельны):
В левой части PBI и Bug, а на самой доске размещаются задачи к ним привязанные. Веб-интерфейс, возможность перетаскивать по доске с изменением статусов задач и даже есть возможность посмотреть кто закрывал какие задачи:
Но нам это не очень подошло, т.к. хотелось контролировать движение по доске не задач, а PBI и Bug. Это связано с тем, что тестирование и документирование требования у нас формализуется как задача к нему привязанная. Или, другими словами, чтобы понять что PBI пора тестировать и документировать можно только по тому, что в нем остались только эти задачи. Не очень удобно. Также для багов мы задач не заводим, т.е. стадия работы над багом определяется по его статусу и... исполнителю. А на этой доске этого не видно. Ну и вторая причина, хотелось "физическую" доску.
Как и положено в гибких методологиях, обсудили чтобы хотелось от доски, выбрали столбцы и пришли к выводу, что задачи распечатывать и клеить на доску, это очень большой объем задач (в итерацию входит порядка 15-25 PBI, а задач порядка 50-80). Т.е. печатать их, перевешивать посчитали, что будет лениво. Я даже распечатал для первого спринта с физической доской стопку PBI и стопку задач. Вторая всех напугала и от них отказались.
Т.к. для физической доски нужно бумажки и поверхность, то для первого было написано небольшое приложение, забирающее из TFS список WorkItem-ов и экспортирующее их в Excel:
А вот так выглядит сформированный файл Excel:
У каждого элемента есть несколько областей:
Ок, бумажки готовы, осталось дело за доской. На первом этапе, с мыслями, а вдруг не пойдет, пошли по самому простому пути. Воспользовались изолентой:
Т.к. PBI и Bug проходят через 4 стадии во время спринта: "сделать", "в работе", "в тестировании", "готов", то решили не мудрствовать лукаво и выделить на доске именно эти колонки. У PBI есть еще Документирование, но т.к. оно идет параллельно с тестированием, то отдельный столбец под него делать не стали.
Чтобы нагляднее было оценивать текущую ситуацию, баги помечены красной изолентой, а PBI синей.
Как происходит движение бумажек по доске? Сначала все попадает в первый столбец (Сделать). Разработчик начиная работу по багу или PBI перевешивает листик во второй столбец (В работе). Про порядок выбора в работу, чуть ниже. Заканчивая работу над багом или над последней работой по PBI типа Development разработчик перевешивает бумагу в третий столбец (Тест). По закрытию бага или задач на тестирование и документирование бумажка перевешивается в последний столбец (Готово). Попробовав несколько итераций, я перестал печатать бумажки на доску. И... поступили предложения вернуть доску.
Была заказана пробковая доска, ну а после того, как мне попалась на глаза бумага для принтера разных цветов доска приобрела следующий вид:

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

2. PBI остались синими, но у них кнопки стали разных цветов. Синяя - PBI которые был взят в спринт при его планировании. Селеная - PBI это строчное требование добавленное в процессе спринта.

3. Появилась стрелка. Т.к. самых приоритетных задач много быть не может, то стрелка всего одна. Если появляется что-то, что требует к себе максимального внимания и прохождения до статуса Готово за минимальный срок, то рядом с его бумажкой вешается стрелка. И бумажка перемещается из столбца в столбец с этой стрелкой.
На текущий момент, это все. Ну а какой наша доска будет через год... Спросите меня об этом в октябре 2015 года.

Драйверы и разработка программного обеспечения


Эта статья подготовлена для блогов журнала PCWeek.

Работа стремится занять все время, отпущенное на нее.
Закон Паркинсона.

Предлагаю поговорить об одном из взглядов на проблему, озвученную в эпиграфе. Почему, сколько бы времени мы не закладывали на задачу, она решается точно в срок или позже? Тайби Кэлер, дорабатывая теорию транзитивного анализа, ввел понятие микросценариев (микроскриптов) поведения, которые могут длиться от нескольких секунд до нескольких минут. Контрпродуктивные сценарии Т. Кэлер выделил в отдельную группу и назвал драйверами. При дословном переводе мы получаем этаких кучеров, которые заставляют нас бежать по однажды проторенному маршруту, не давая свернуть.
Известны пять драйверов :
1.Будь лучшим
2.Радуй других
3.Старайся
4.Будь сильным
5.Спеши
Кстати, относительно проявления драйверов в профессиональной деятельности чаще употребляют выражение «личностный стиль» или «рабочий стиль». Давайте рассмотрим эти драйверы и то, как они влияют на нашу работу.
Будь лучшим
Как и остальные драйверы, этот получил свое название от благих намерений, которыми родители потчивали всех нас в детстве. На первый взгляд, он выглядит вполне безобидным и даже полезным. Действительно, человек запрограммированный этим драйвером, как правило, эрудирован, проявляет интерес к новым знаниям и дискуссиям. Но, с другой стороны быть лучшим - это огромная ответственность, надо все знать и уметь, никогда нельзя ошибиться. Не зная ответа на вопрос, можно сослаться на громкую фамилию, особенно если книги этого автора никто не читал (Кнут, Страустрап у всех на слуху, но немногие осилили ту же «Теорию алгоритмов»). Начиная разбираться в уже существующем проекте, «лучший», обычно начинает с фразы: «А почему у вас все так плохо? Ведь лучше будет вот так!». А это «вот так» возвращает нас к затратам времени на решение задачи. Ведь ошибиться нельзя! Ага, задача на 5 часов? Хорошо! Построим план работ, выверим его до последней детали. Что, здесь «некрасивая» связка с другой системой? Ничего страшного, перепишем ее. Написали? Ого, остался еще один час на задачу, можно еще улучшить вот здесь и здесь, а также поправить вон в том модуле. Нет, он мне не нужен, но кто же так пишет? И вот, прошло уже не пять и даже не шесть часов, а улучшения продолжаются и продолжаются. Причем, даже остановиться не получается, так как ничего не работает, пока не доделаешь здесь и чуть-чуть вон там.
Для борьбы с этим драйвером необходимо понять, что ошибки — это несмертельно, снижение планки и установление реальных целей – это не конец света, а чуть меньше критики окружающих не ухудшит их мнение о вас, а, наоборот, улучшит.
Радуй других
Человек с этим драйвером вынес из детства волшебное решение: «если я буду всем нравиться, то все у меня будет хорошо». И вот у нас появляется безотказный коллега. С какой просьбой к нему не обратишься - он всегда рад помочь. Доотладить скрипт, доделать модуль, задержаться после работы. Да, такие люди всегда на хорошем счету у начальства, к ним хорошо относятся в коллективе. Но рано или поздно, особенно, если наш «душка» стал руководителем, объем просьб превышает разумные пределы, и человек, не умеющий сказать нет, начинает решать сто задач одновременно. У него на задачу целых пять часов, но ведь надо помочь Степану, да и Маша просила сходить с ней на обед. И даже если есть подчиненные, передать часть своих работ им не позволяет драйвер. Ведь они начнут относиться ко мне хуже, а этого нельзя допустить. И вот, сроки задачи сорваны, появляются невыполненные обещания, проваленные проекты. Похоже, что из-за желания нравиться другим сгорело больше руководителей проектов, чем по всем остальным причинам.
Для борьбы с этим драйвером нужно не только себя ставить на место других, но и других на место себя. Не надо «читать мысли», задавать больше вопросов и выяснять реальные потребности окружающих. И да, немного здорового эгоизма не помешает.
Старайся
Человек с этим драйвером верит в процесс. Если он будет стараться, то кто-то поможет ему: может быть, коллега, а, может, вселенная, и все будет хорошо. Не важен результат, ведь есть процесс, к которому прикладываются все силы. Ну, не получится сразу, попробую еще раз, а потом еще и еще… Вы уже узнали Сизифа. Зачем он тащит камень на гору? Почему он каждый раз скатывается? Все это не важно, главное - стараться. Начиная любое дело, носитель этого драйвера сначала продумывает пути отступления, ведь важнее сохранить статус-кво, чем идти вперед. Ах, на задачу пять часов? И я ее не решил? Но я ведь старался, я искал три часа в гугле, потом спрашивал у Пети. Я вон какую стратегию проработал для решения задачи, у меня только разветвлений на ней больше двух десятков. А результат? Ну да, нет результата. Но я ведь старался!
Чтобы победить этот драйвер, надо перестать гордиться процессом. Взялся за дело - доводи его до конца. Ориентация на результат - вот главный метод борьбы.
Будь сильным
Помните из детства: "Не плачь, ты же мальчик"? В результате образуется драйвер, заставляющий казаться сильным. Ведь если показать, что ты сильный, то проблема испугается и убежит. Обратиться за помощью к коллеге? Однозначное нет! Я ведь сильный! Посчитать риски, которые могут возникнуть в процессе работ? Зачем, ведь все пройдет идеально. А там, где будет неидеально - я сильный, я справлюсь. И вот, перед нами список задач, который можно решить только в идеальных условиях. Проблемы, возникающие в процессе решения задачи, будут до последнего преодолеваться в одиночку. А ведь можно еще пойти не по простому пути, а по сложному, а то вдруг кто-то усомнится в моей силе. Поэтому за пять минут до запланированного срока задачи проекта от человека с таким драйвером можно будет услышать: «Я думал, я все успею исправить».
Итак, если вы углядели в своем поведении этот драйвер, то расслабьтесь. Нет, не в смысле «Расслабьтесь, все у вас хорошо», а в смысле «Научитесь расслабляться, иногда быть слабым, и не стесняйтесь просить коллег о помощи».
Спеши
Этот драйвер редко бывает главной движущей силой. Как правило, он идет в комплекте с другим, более сильным драйвером, например, «Старайся». Человек начинает спешить не чтобы успеть, а чтобы не опоздать. В отличие от остальных драйверов, которые обещают волшебный результат, этот запугивает: «Если ты не будешь торопиться, то все пропало». Такие люди очень сильно подвержены манипуляциям на дефиците: «Еще чуть-чуть, и ты опоздаешь», «Осталось всего два часа до окончания оплаты» и т.д. Они всегда спешат, все время взгляд на часы, быстрая пулеметная речь. Получив задачу на пять часов, программист с этим драйвером бросится в работу, ведь надо успеть. Но у него очень быстро возникнут еще более срочные дела, которые надо успеть. Пришло новое письмо? Спеши, надо успеть прочитать! Возникла новая задача? Спеши, надо успеть забрать ее себе!
Для борьбы с этим драйвером нужно сложные задачи разбивать на более мелкие и в единицу времени решать только одну. И, самое главное, не стараться успеть все.
Если верить Тайби Кэлеру, то у всех нас, в той или иной мере, выражены эти драйверы. Какие-то более ярко, какие-то менее. Чем чаще мы даем драйверу власть над своим поведением, тем более естественен и привычен он будет для нас. Поэтому, узнав у себя описанные выше сценарии поведения, надо остановиться и подумать: «Может, пора отнять управление своей жизнью у драйвера и передать его себе?»

Строили два товарища


История от начала до конца выдумана, все совпадения с реальностью случайны.

Два друга детства Сергей Водопадов и Антон Гибких мало того, что работали в одной организации, так еще и участки для строительства дома купили по соседству. Строиться начать решили в апреле.


Сергей Водопадов подошел к вопросу основательно, в выбранной для строительства компании был утвержден проект, была составлена смета и установлена дата приемки готового дома. В компании Сергею сказали, чтобы не волновался и приезжал в сентябре принимать готовый объект. А вот Антон нашел компанию, которая ему предложила странное. Ни тебе конкретного срока, ни конкретной цены и даже проект приблизительный. Да еще и предложили раз в две недели встречаться на объекте. Когда Сергей и Антон только еще заключали договора, Сергей начал стебаться над Антоном:

– Ха, разведут они тебя. Как это строить дом по примерной смете?

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

Каждый раз, после такой встречи Антон от Сергея слышал:

– Ага, а я тебя предупреждал. То ли дело у меня, заплатил сколько договорились и до приемки свободен. А ты и платишь все больше и больше, да и мотаешься туда постоянно.

Вот так и подошел сентябрь. Правда, Антону и принимать особо было не чего. За две недели с прошлой встречи так, мелкие доделки до ума довели. А вот у Сергея приемка проходила не скучно. Выяснилось, что к заявленному сроку к крыше еще не приступали, а осенние дожди то уже на носу. Цвет дома был ужасен, лестница на второй этаж была из… Ну из песни слов не выкинешь, была прямо из туалета первого этажа. Да, вы угадали унитаза там не было. Зато прямо через спальню проходил стояк санузла второго этажа. И как же он звучал, когда на втором этаже… Прошу прощения, что-то отвлекся. Комнаты оказались темные из-за маленьких окон, ну и так далее, и тому подобное.

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

Парадигма Кеневина и разработка программного обеспечения

Эта статья подготовлена для блогов журнала PCWeek.
Теория запутанности (сложности), предложенная Дейвом Сноудоном в начале двадцать первого века, несмотря на свою молодость, уже нашла применение в кибернетике, менеджменте и биологии. Сегодня я предлагаю обсудить парадигму Кеневина в применении к разработке программного обеспечения.

Владеющие английским могут посмотреть вот это видео (ссылка http://www.youtube.com/watch?v=N7oz366X0-8), в котором сам автор описывает парадигму. Для остальных кратко изложу ее суть на русском.
Итак, в теории запутанности понятие «система» немного отличается от привычного многим, поэтому начну с нескольких определений:
Артефакт - материальный ресурс, имеющий определенное положение и реагирующий на действия агентов.
Агент - коллекция свойств, стратегий и возможностей для взаимодействия с артефактами и другими агентами.
Агентами могут быть как отдельные люди, так и группы людей, правила, идеи и т.д.
Система – некая сеть, включающая одну или несколько групп агентов, и, возможно, артефакты.
Обратите внимание, что в отличие от классического понимания систем, в данном определении отсутствует понятие цели.
В рамках парадигмы Кеневина все окружающие нас системы делятся на три большие группы. На одном конце оси координат находятся упорядоченные системы с жестко ограниченными агентами, характеризующиеся детерминированностью и независимостью от наблюдателя. К таким системам можно отнести конвейер, армию, разработку медицинского оборудования. На другом - хаотические системы, в которых агенты не зависимы от системы и друг от друга. Примером такой системы может быть попытка сплавиться по Ниагарскому водопаду в бочке и предсказать, как эту бочку с находящимся в ней человеком будет крутить и куда выбросит. Ну, а между ними находятся запутанные системы. Такие системы, с одной стороны, ограничивают своих агентов, а с другой - агенты оказывают влияние на систему и друг на друга, в результате чего все это коэволюционирует, и процесс этот является необратимым. Примером может послужить большинство коммерческих организаций, живые организмы и даже кружки по интересам.

Для упорядоченных систем характерно наличие экспертов. В простых системах мнения экспертов сходятся, и есть понятие лучших практик (Best practice). Достаточно действовать в соответствии с этими практиками, и результат будет гарантирован. Все, кто не придерживаются Best practice, начинают проигрывать. В упорядоченных сложных системах разные эксперты могут предлагать разные пути решения, получая одинаково хорошие результаты. Для примера можно взять двух хороших программистов и попросить их выполнить некую задачу. Решения будут отличаться, а вот результаты будет практически идентичными. В данном случае идеального пути нет, но можно выделить несколько достаточно правильных.
В запутанных системах экспертов нет. Да оно и понятно, ведь такие системы имеют множество агентов, взаимосвязи между которыми разнообразны и запутанны. Очень часто в таких системах можно найти факты, противоречащие друг другу. Даже небольшое воздействие на систему может привести к сильным изменениям. В таких системах приходится идти методом проб и ошибок: Попробовали? Дало положительный результат? Продолжаем, а если нет, то давайте сделаем что-то другое.
Хаотичные системы не поддаются анализу. В них нет вообще никакой структуры. Поэтому главное в такой ситуации - начать действовать. Правильно или неправильно - понять не возможно, но так как  состояние хаоса заканчивается очень быстро, то по его завершении мы и узнаем, правильной ли дорогой мы шли. Как правило, те, кто идут, оказываются в более выигрышной позиции по сравнению с теми, кто во время хаоса ничего не делал.
Теперь давайте посмотрим на разработку ПО через призму изложенной теории. Если у нас проекты простые и без изменения требований (правый нижний угол), то можно применять водопадные методики «и в ус не дуть». Если система упорядоченная, но сложная, то можно воспользоваться любой устоявшейся инженерной практикой, будь то PMI или PRINCE2. В зоне же запутанности хорошо себя покажут итеративные подходы к разработке - Scrum или Kanban. Ну а в хаосе можно пробовать все. Если придет жесткий диктатор - появится шанс перейти из хаоса в жестко упорядоченный правый нижний угол, поведет за собой открытый для внешнего мира лидер - попадете в правый верхний квадрат. Даже если вы ничего делать не будете, то хаос вас выкинет хотя бы в зону запутанности.
Главное - не забывать, что все эти зоны субъективны. Вспомните свой первый день на первом месте работы. Все вокруг непонятно, куда-то движется, кто-то с кем-то обсуждает вещи, даже названия которых вы не слышали. Но для окружающих это все могло быть упорядоченной системой с детерминизмом в основе. Да и для вас через несколько дней или недель это был уже не хаос, а система.
Тоже самое происходит и в разработке. Когда вы запускаете новый проект, все запутанно. Гибкие методологии позволят в параллельном или последовательном эксперименте проверить гипотезы, оценить трудоемкость тех или иных задач, определить производительность команды и т.д. Но в дальнейшем может иметь смысл перейти на более формальные подходы к управлению проектом, построить диаграмму Ганта, запланировать буферы, составить реестр рисков. Само собой, многие практики из PMI можно применить и в запутанных системах. Никак не лишним будет список заинтересованных лиц или устав проекта. Но использовать многие другие практики окажется нецелесообразным. Тем не менее, важно о них знать и пробовать применять, чтобы в максимально короткие сроки перейти к упорядоченному состоянию системы.