Удаленная работа - несколько мыслей

Я довольно долгое время уже работаю с людьми, находящимися от меня на "расстоянии" 8 и более часов. Кроме того, некоторых людей, с которыми я работаю, я не знаю лично. Такая ситуация создает специфические проблемы, которых не бывает при работе в офисе.

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

1. Вы должны быть в состоянии предложить удобный способ оплаты ваших услуг. Уточнение: webmoney и yandex-деньги - НЕ являются удобным для всех способом . На самом деле, желательно иметь несколько способов. Самым удобным было бы если бы у вас был банковский счет в долларах, на который можно было бы перевести вам деньги. Paypal тоже работает. Необходимость наличия удобного способа оплаты связана с тем, что когда я начинаю с вами работать, я хочу быть сосредоточен на рабочих моментах: что нужно сделать, когда, как, в какие сроки. Я не хочу думать о "логистике".
2. У вас естественно должно быть удовлетворительное подключение к интернет:
• возможность (достаточно "широкий" канал) разговаривать по скайп или ему подобным программам
• email
• интернет-пейджер (icq, aim, google talk, тот же скайп)
• возможность передавать достаточно большие файлы
• наличие ftp (в некоторых проектах)
3. Мобильный телефон для связи - так чтобы я до вас можно было добраться, когда вы не за компьютером. Понятно, что телефоном этим никто не будет (не должен) злоупотреблять, но он необходим, учитывая разницу во времени.
4. На письма необходимо отвечать. Даже если ответ состоит в том, что вы сделать ничего не сделали. Отсутствие ответа создает неприятнейшее ощущение того, что вы пропали. Это особенно касается "одиноких волков".
5. Перед высылкой, код необходимо тестировать. Банально, но иногда создается ощущение, что высланное не запускалось автором никогда. Опять же, особенно касается одиночек.
   P.S. По этому поводу могу рассказать два анекдота
• Автором известного учебника "Искусство программирования" Дональд Кнут, как то написал в письме: "Beware of bugs in the above code; I have only proved it correct, not tried it" (http://www-cs-faculty.stanford.edu/~knuth/faq.html)
• Одного моего коллегу как-то спросили "Ну что, написал программу-то?" Тот ответил: "Да". В этот момент спрашивающий уточнил - "Ну то есть она уже готова?" Ответ был простой: "Нет конечно, я её только написал, но не запускал ещё".
6. Используйте в письмах тот же язык, на котором написано исходное письмо. Если я пишу Вам письмо по-русски - отвечайте по-русски, если по-английски, то по-английски.
7. "Было бы величайшей ошибкой думать". Это не так. Думать нужно. И если я прошу глупость - не грех сказать мне об этом. Будет полезно всем. Нет смысла слепо делать все, о чем вас просят, только потому что просят "с той стороны". С той стороны ошибаются не меньше чем с этой и уточнить задачу, высказать свои соображения очень желательно.

Про офис

Нужен ли офис в программистской компании? Почему бы собственно программистам не сидеть дома, писать себе спокойно программы? Интернет сейчас быстрый поставить недорого. Средства обмена информацией есть в огромном количестве - недорогие и много чего умеющие. Электронная почта, телефон, разнообразные интернет-пейджеры, в том числе и поддерживающие разговоры голосом, телеконференции. Да и показать что происходит можно легко - есть и WebEx и Netmeeting и GoToMeeting и ещё масса подобных программ.

Зачем же нужен офис - за него ведь деньги платить нужно[имеется ввиду за аренду], к тому же в него нужно ездить - тратить время на дорогу.

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

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

Про письма

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

Так уж сложилось, что я уже довольно долго работаю именно в компаниях, разработка программ в которых ведется в Москве. И я бывал с обеих сторон - и с американской и с московской. Знаете, в чем состоит самая большая проблема с "той", "американской" стороны? Непрозрачность. Непонятно что происходит. Успевают ли с проектом? А если не успевают, то почему?

Есть масса вещей, способствующих непрозрачности команды программистов. Языковый барьер, который присутствует просто потому что для одних родной язык русский, а для других английский. Сам факт того что люди сидят далеко друг от друга. И ещё отсутствие писем.

Совершенно необходимо писать письма и отвечать на письма. Это единственный надежный инструмент общения. Далеко не все в США пользуются ICQ или "впишите-здесь-имя-своего-любимого-интернет-пейджера". На любое письмо должен быть ответ. Даже если в ответе написано, что настоящий ответ будет завтра. И завтра, если настоящего ответа нет, нужно опять написать что ответ будет завтра. Это очень простой и на самом деле самый верный способ дать своим коллегам на "той" стороне уверенность что их читают, о них помнят и вообще что с той стороны хоть что-то происходит.

Пишите письма!

Отчет об ошибке

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

Поэтому я завязываю с предисловием и перехожу к сути дела.

1. Перед тем как добавить новый отчёт об ошибке (новый баг, CR типа дефект, называйте как хотите) необходимо убедиться что его ещё нет в системе.
   
   
2. Уточнить о какой версии продукта (и модуля, и если нужно подмодуля) идет речь. До последней цифры, даже если их 18.
   
   Например: Программа Феликс, версия 4.2.1121.1356b
   
   
3. Описать проблему в примерно таком порядке:
1. Краткое описание
   Неправильное сложение отрицательных чисел
   
2. Последовательность шагов, которую нужно проделать для того чтобы проблему воспроизвести
• Ввести операцию сложения (ну может Феликс в польской записи работает :-) )
• Ввести '-2' в качестве первого аргумента
• Ввести '-3 в качестве второго аргумента
• Нажать на кнопку получения результата
  
3. Ожидаемый результат - вы думали что когда это проделаете, то получится то-то
   Ожидали получить -5
   
4. Полученный результат - а на самом деле получилось ....
   Получили -1
   
5. Существует ли способ получить ожидаемый результат (способ обойти ошибку)? Если да, то какой?
   Да, если сначала ввести -3, а потом -2 то сложение выполняется верно
   
4. Все сообщения об ошибках должны быть обязательно приведены (желательно в виде скриншота)
   Сообщений об ошибках не выдаётся
   

И все ...

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

MRD: Marketing Requirements Document

Уже почти год назад я писал о ролях в разработке программного обеспечения. А именно о том, в чем состоят обязанности людей, играющих определённые роли и на чьей стороне (заказчика или разработчика) они играют.

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

Хочу только сказать, что все о чем я здесь говорю - никакой не стандарт или правило. Каждая компания на самом деле сама определяет роли и необходимость наличия документов и что в этих документах должно быть написано. Я рассказываю о своём опыте и своём понимании этих процессов.

---

Я хочу сегодня рассказать про один из аспектов взаимодействия Product Manager (в терминах моей старой статьи) с разработчиками, заказчиками и высшим руководством.

Замечу, что под разработчиками здесь я понимаю не только программистов, но также и тестировщиков и технических писателей и работников технической поддержки и специалистов по внедрению. Соответственно "команда разработчиков" включает в себя (при необходимости конечно) всех этих людей.

Напомню, что Product Manager:

Отвечает за продукт с точки зрения заказчика. То есть product manager — это человек, представляющий заказчика в команде разработчиков. В обязанности Product Manager входит:

1. Исследование рынка
2. Выявление потенциально нужных заказчикам продуктов, сервисов, функциональности
3. Исследование конкурентов (иногда этим занимаются специально выделенные люди)
4. Маркетинговые исследования, PR акции, пресс-релизы (иногда эту работу делают специальные Product Marketing Manager, иногда она производится совместно этими двумя ролями)
5. Выработка списка "features" продукта
6. Определение приоритетности тех или иных "features" (что делать обязательно, что нет)
7. Позиционирование продукта (на какой рынок продукт нацелен, портрет покупателя)
8. План развития продукта (RoadMap)
9. Ценообразование (сколько продукт будет стоить, какая будет модель лицензирования)
10. Взаимодействие с высшим руководством компании, если таковое необходимо
11. Взаимодействие с отделом продаж и совместная выработка стратегии продаж

Взаимодействие с разработчиками происходит как формальное, так и неформальное. Основным формальным документом, который является результатом работы Product Manager и определяет продукт для разработчиков и является MRD - Marketing Requirements Document.

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

Ну то есть MRD - это документ при помощи которого Product Manager (человек представляющий заказчика и, в теории, знающий что тому нужно) пытается донести нужды заказчика до разработчиков.

Теперь попробуем описать какие разделы должен включать MRD. Для удобства я попытаюсь сразу после описания соответствующего раздела давать пример.

MRD представляет из себя документ, в общем, свободного формата. Основная аудитория MRD - это:

• Разработчики
  Разработчикам MRD необходим для понимая того что же именно нужно написать.
  
  
• Высшее руководство
  Ну, во-первых, начальство конечно должно быть в курсе что собственно делается ;-) Во-вторых, MRD - это документ, являющийся обоснованием для получения ресурсов (материальных и людских), если их не хватает.
  
  
• Заказчик
  Заказчику MRD предоставляется в составе более широкого пакета документов, для утверждения. В случае возникновения споров по поводу наличия или отсутствия той или иной функциональности MRD является документом, который помогает их разрешению.

Помня о нашей аудитории и целях создания документа, опишем его составные части:

MRD для нового продукта "Феликс"

1. Цель создания продукта или выпуска очередной версии.
   В данном разделе описывается проблема, существующая у потенциальных или реальных заказчиков и объясняется, как именно продукт или новая версия продукта эту проблему устранит. Это очень важный раздел, он должен сравнительно кратко объяснить что же именно предстоит сделать.
   
   Пример: Не все люди достаточно хорошо могут считать "в уме". Особенно плохо это получается у людей, если числа являются не целыми и достаточно большими. Во многих магазинах существует проблема ошибок кассиров, которые, высчитывая цену покупок "на бумажке", часто ошибаются. Это приводит к недовольству покупателей (если кассир ошибается не в их пользу) или же к потерям самого магазина. Недовольные покупатели могут перестать приходить в этот магазин и, таким образом, также снизить доходы. Проблема очень велика и статистика показывает, что расходы магазинов связанные с потерями при арифметических подсчётах, увеличиваются с каждым годом:
   

   Год	Потери
   2004	$200млн.
   2005	$300млн.
   2006	$400млн.

   
   Продукт "Феликс" предназначен для того, чтобы помочь магазинам справиться с описанной проблемой. Он будет представлять из себя небольшую программу, которая может быть запущена на мобильном телефоне кассира и поможет ему подсчитывать суммы, которые раньше ему приходилось считать на бумаге.
   
   
2. Описание того, какой результат должен быть достигнут и в какие сроки.
   Здесь необходимо описать что именно должно получиться (web-сервис, java-приложение, некоторый документ, который описывает что-то, некоторое устройство, обладающее определёнными характеристиками). Также в этом разделе обычно указывается желаемый (с точки зрения заказчика) срок получения продукта. Хочу специально отметить, что это не срок, за который продукт будет сделан. Это всего лишь желаемый срок. MRD проходит в своём развитии много итераций и реальные сроки исполнения в нем обычно не указываются. Заказчику сроки исполнения обычно предоставляются в других документах. Тем не менее указать желаемое время (например некоторое важное с маркетинговой точки зрения событие) здесь вполне возможно.
   Пример: Поскольку по результатам исследований выяснилось, что большинство кассиров в магазинах пользуется мобильными смартфонами с установленной на них операционной системой компании Microsoft - Windows Mobile 6.0, то Феликс должен представлять собой программу работающую под управлением этой и последующих версий ОС Windows Mobile 6.0. В сентябре следующего года ожидается всемирная выставка Кассир-2008 в Лас-Вегасе и первую версию программы очень желательно иметь к этому времени, для того чтобы мы могли разрекламировать её во время выставки.
   
   
3. Описание функциональных возможностей продукта.
   Данный раздел собственно и составляет самую большую часть MRD - в нем описывается какие именно функции должен выполнять продукт. В зависимости от самих функций, квалификации Product Manager и принятых в компании правил, раздел может быть более или менее подробным. В частности, подробные сценарии использования (use cases) каждой из функциональных возможностей могут присутствовать, а могут и нет. Также MRD может включать или не включать в себя внешний вид пользовательского интерфейса. В любом случае, сценарии использования и внешний вид пользовательского интерфейса обычно появляются на той или иной стадии разработки и обычно являются дополнениями к MRD, поскольку дают более полное представление о продукте.
   
   Описание каждой функциональной возможности обязательно должно включать в себя её приоритет - насколько важна эта возможность с точки зрения заказчика.
   Приоритет важен, поскольку в какой-то момент, при разработке проекта часто появляется необходимость пожертвовать какими-то функциональными возможностями. Помочь решить какими именно и может знание важности каждой конкретной возможности для заказчика.
   
   Пример: Феликс должен обладать следующими возможностями:

• Сложение действительных чисел, при помощи стандартных правил сложения, описанных в учебнике Г.М. Фихтенгольца
  Приоритет: очень важно
  
• Вычитание действительных чисел, при помощи стандартных правил вычитания
  Приоритет: очень важно
  
• Умножение действительных чисел
  Приоритет: очень важно
  
• Деление действительных чисел
  Приоритет: очень важно
  
• Скорость выполнения операций не должна быть больше 10 секунд на одну операцию
  Приоритет: очень важно
  
• Программа установки, выполненная по стандартам Windows Mobile 6.0
  Приоритет: очень важно
  
• Drag&Drop
  Приоритет: очень важно
  
• Plug&Play
  Приоритет: очень важно
  
• Возможность распечатывать результаты
  Приоритет: очень важно
• Наличие подробной документации по всем функциям программы
  Приоритет: очень важно

Заметили ли вы некоторые странности в последнем примере? Что за удивительная функция Drag&Drop? А что такое Plug&Play? Какое отношение они имеют к программе "Феликс"? А может быть есть ещё какие-то странные требования? А почему собственно приоритет ВСЕХ функций поставлен как "очень важно"? Частенько Product Manager формулирует свои требования не достаточно чётко или само требование не кажется особенно осмысленным. Поэтому составление MRD часто требует нескольких итераций, так что каждая следующая делает этот документ более "внятным".
Для того чтобы уменьшить количество этих итераций, описание функциональных возможностей также иногда делят на части:

• Описание - эта часть у нас уже была
• Приоритет - эта часть также уже была
• Цель - какую задачу решает наличие данной функции. Обычно цель очевидна, а вот если она не очевидна, то может быть и сама функция не нужна.
• Откуда появилась идея - требование заказчиков, наличие такой функции у конкурентов, наличие проблем в существующей версии продукта
  

Такие функциональные возможности, которые предложил Product Manager для программы Феликс - Drag&Drop и Plug&Play возможно являются следствием того, что он бездумно пошёл на поводу у рекламы и просто включил в список пару "красивых" с его точки зрения фраз.

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

Реальное рабочее время

Меня продолжает сильно интересовать проблема оценки сроков проекта. В этой связи я наконец добрался до книги Steve McConnel Software Estimation: Demystifying the Black Art, которая в русском переводе имеет совершенно удивительное название "Сколько стоит программный проект". (на самом деле объяснить название конечно можно, поскольку в содержании книги сроки, затраты или рабочее время считаются более или менее взаимозаменяемыми понятиями).

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

В книге описаны различные способы оценки сроков (или затрат) на выполнение проектов, но меня заинтересовало вот что.

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

Насколько это число соответствует действительности - неважно, лучшего у нас все равно нет. Однако важным является то, учитывает ли это число время, проведённое на работе, но при этом потраченное на "нерабочие дела" - интернет, кофе, перекуры и так далее.

В связи с этим какое-то время назад я организовал на RSDN голосование поэтому поводу. Вот вопрос, который я задавал и результаты голосования:

Вот такие результаты. Думаю, что при планировании очень стоит помнить про то, что не все время, проведённое на работе, действительно уделяется работе.

Замечания

Там же, на RSDN, к данному опросу было дано несколько замечаний, на которые я думаю важно ответить. Я здесь попробую кратко отразить замечание и дать на него комментарий.

1. "Подобные подсчеты бессмысленны". Бизнес сторона программирования требует выдачи сроков. Более того, часто невозможно даже давать сроки по Steve McConnel - при помощи диапазонов. И человеку, который должен составить оценку волей или неволей приходится выдавать прогноз. И лучше если у него есть понимание того, что выданная оценка скажем в 5 часов рабочего времени - это в реальности два рабочих дня.
   
2. "Настоящий программист может думать о работе и дома и во время отдыха, поэтому непонятно что считаем". Действительно, это так. И действительно это не особенно то и подсчитаешь. Программа подсчёта рабочего времени может подсчитать сколько времени у меня на экране была открыта Visual Studio, но вряд ли догадается, что я в это время думал про то, как здорово понырял в красном море. Тут мой ответ таков - лучше хоть какие-то, пусть даже заниженные оценки, чем никаких.

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

17458907.195e50a0db7e7428ccd693c67f635406.1186223110.9626a2d31cf793845f340f27c23ea8b8

К вопросу о "стандартах кодирования"

На форуме Artima Developer Spotlight появилась тема: "What's the Most Effective Code Style Policy?", посвящённая обсуждения "стандартов кодирования".

Немного о терминологии

На самом деле даже сам термин "coding policy" или "стандарты кодирования" многозначен. Разные авторы или компании вкладывают в него разные смыслы, в зависимости от которых область применения стандартов может быть существенно сужена или наоборот расширена.

Рассмотрим возможные смыслы термина:

1. Стиль и синтаксис форматирования исходного кода программы
• Расстановка скобок
• Использование пробелов и пустых строк
• Правила написания выражений (for, if, while и так далее)
• Правила именования переменных
• Правила объявления переменных
• Правила написания комментариев
• Правила использование отступов
2. Иногда к содержанию первого пункта могут быть добавлены элементы "управления конфигурацией"
   
• правила именования файлов
• структура файлов проекта
• правила использования системы контроля версий
• стандартизация используемых средств разработки
  
3. Иногда к стандартам кодирования могут также быть добавлены "best practices" того, как надо писать программы, в зависимости от определённого языка программирования, среды разработки, компании или специфики разрабатываемого продукта (типичным примером может служить требование "всегда создавать в классе виртуальный деструктор", для C++)

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

Мой взгляд

Здесь я хочу ответить на вопрос, заданный в теме на форму Artima - "What's the Most Effective Code Style Policy?".

Обращаю внимание, что все дальнейшие рассуждения касаются "стандартов кодирования" в смысле (1) и оставляют аспекты (2) и (3) без внимания.

Основной необходимостью существования "стандартов кодирования" обычно называют (некоторые части процитированы по Code Conventions for Java Programming Language, они отмечены '*'):

1. Необходимость работ над одним и тем же исходным файлом нескольким программистам
2. Улучшение "понятности" исходного кода, что позволяет программистам более полно и быстро понять новый для них код (*)
3. Необходимость сопровождения (исправления ошибок, внесения небольших исправлений) кода и тот факт что в большинстве случаев споровождение осуществляется не тем же человеком, который является исходным автором кода. (*)
4. Программист, работающий над исходным кодом, который написан не в "любимом" или "привычном" стиле будет тратить на его исправление больше времени (аргумент Bill Venners из исходного сообщения в форуме).
   

Моё мнение состоит в том, что усилия на создание и поддержание "стандартов кодирования" в большинстве случаев существенно выше чем затраты на "понимание" или поддержку кода, написанного "в другом стиле". Я конечно не имею ввиду примеры из "Obfuscated C Code Contest" :-) В большинстве случаев, код написанный вменяемым программистом понятен другому вменяемому программисту, вне зависимости от того, как именно расставлены в нем фигурные скобки или именованы переменные. Единственной неприятностью могут быть различия в настройках отступов и табуляций/пробелов, при просмотре кода различными текстовыми редакторами, просмотрщиками и программами сравнения.

Поэтому в моей голове всегда существовал такой "стандарт кодирования":

1. Единообразная настройка длины табуляции (tab length)
2. Использование пробелов вместо табуляций
3. При правке кода пользоваться тем стилем, который используется в этом коде

Вот собственно и все. А если Вы или Ваш коллега пишете код в стиле "Obfuscated C Code Contest", то подумайте может проблема должна быть решена не при помощи "стандартов кодирования", а как-нибудь по-другому?

17458907.195e50a0db7e7428ccd693c67f635406.1186161181.ba176d26a55281a16d8fd8b02a541ce8
17458907.48319b4763d4aa2700c0fda3363b9fab.1186391267.b8da257c7d1fa1c830df3b9f73d6fb72

О совещаниях ...

Почему-то последнее время вокруг меня часто всплывает тема о совещаниях. И люди говорят, и на RSDN тема появилась.

Я очень уверен в том, что почти всегда совещания на самом деле не нужны. Ну, то есть, в подавляющем большинстве случаев все полезное, что делается во время совещания, можно сделать и так, в рабочем, что называется, порядке.

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

Ну то есть, конечно поймите меня правильно, совещания нужны. Но не всякие и не всегда.

В моей голове есть три типа совещаний.

1. Совещания, которые необходимо провести, поскольку что-то произошло.
   
   Скажем выяснилось, что по какой-то причине код в проекте раздублирован, то есть нарушен принцип DRY. В этом случае необходимо конечно устроить небольшое совещание с участием тех, кто этот принцип нарушил и договориться о том, как решить проблему
   
   
2. Совещания, которые необходимы для определения 'общего направления', создания 'единого видения', 'одинакового понимания' и тому подобного
   
   
3. "Регулярные" совещания. Еженедельные "status meetings" и так далее
   

Важность и необходимость этих совещаний распределена на мой взгляд в порядке перечисления. То есть, самыми важными и действительно необходимыми являются совещания типа (1), менее нужны совещания типа (2) и самыми ненужными являются совещания типа (3).

Удивительным фактом при этом является то, что количество совещаний (по моему опыту) распределяется совершенно противоположным образом. То есть регулярные совещание проводятся очень часто (регулярно :-) ), совещания второго типа ("объединяющие") время от времени, а вот совещания первого типа (срочные) частенько "задвигаются" и объединяются с совещаниями типов (2) и (3).

И это ужасно! Ведь на самом деле совещания типа (1) - это и есть моменты, когда совещания действительно нужны. Что-то произошло, а следовательно необходимо срочно предпринять меры. Они происходят в тот самый момент, когда обнаружилась проблема и когда свежи в головах её причины, а значит легче всего найти решение.

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

Что же до третьего типа ... Мне кажется, что совещания типа (3) - considered harmful :-).
По нескольким причинам:

1. Если вопросы, которые поднимаются на этих совещаниях, не были ранее подняты на совещаниях двух других типов, то значит они были отложены, ими просто не захотели заниматься, а чего в этом хорошего?
   
   
2. Реальный статус проекта начальник может узнать непосредственно у подчинённого ("в рабочем порядке"), для этого нет необходимости созывать всех и заставлять каждого слушать ответы остальных и ждать своей очереди. (Хочу обратить внимание, что если у начальника слишком много подчинённых, то это само по себе является проблемой. Оптимальное количество подчинённых, по всей видимости, является равным оптимальному количеству сущностей, которыми может одновременно оперировать человек, то есть 7+-2 G. Miller. Magical Number Seven)
   
   
3. Если начальник узнает состояние дел у своих подчинённых раз в неделю, а остальное время находится в неведении ... то он плохой начальник
   
   
4. Очень часто подобные совещания носят ритуальный характер (то есть совещания в которых важна сама форма поклонения боссу). Если подобные совещания нужны начальнику для поддержания собственной значимости, то не совсем понятно стоит ли это того, чтобы тратить столько времени подчинённых (взято из Tom DeMarco, Timothy Lister Peopleware: Productive Projects and Teams)
   
   
5. Если ритуальные совещания нужны для поддержания в подчинённых "желания работать", то не значит ли это что какие-то другие притягивающие силы в организации отсутствуют (например, зарплата недостаточно хороша ;-) )?

Поэтому, когда Вам, как начальнику, хочется провести совещание третьего типа ("Отныне каждый вторник в 10 утра мы будем обсуждать статус проекта!") задумайтесь - "Может, что-то в консерватории подправить?"

Принцип DRY

Про принцип DRY все знают. Ну даже если кто-то и не знает самого сокращения, то уж смысл известен наверняка. Напомню, DRY расшифровывается как Don't Repeat Youself. То есть "Не повторяй самого себя". Первый раз с самим сокращением я столкнулся в книге The Pragmatic Programmer: From Journeyman to Master. На самом деле принцип все мы знаем очень давно, даже если не осознавали его как "принцип" или что-то глубоко умное и философское (в Википедии принцип относится к категории Software Development Philosophies).

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

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

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

Тем не менее, во многих случаях следование этому принципу сильно может облегчить жизнь программистам работающим над проектом. Сузим немного область применения принципа (авторы указывают что его можно применять буквально ко ВСЕМ составляющим ПО - не только исходному коду, но и документации, системам сборки, требованиям и так далее).

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

Откуда берутся такие ошибки? Кто в них виноват?

Программисту, которому необходимо добавить новое поле в диалог плюётся "Вот "@#$%^&*! Ну кто так пишет! И диалога два, и поведение в них чуть-чуть разное и по разным принципам они написаны, и сопутствующие классы разные!" После этого он открывает историю в системе контроля версий, смотрит фамилию предшественника и ... Ну сами понимаете. Тут уж предшественнику вполне может достаться по первое число. Зачем скопировал? Почему все то же самое, но чуть-чуть по-другому?

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

А потом наступает момент когда кому-то нужно добавить в диалог ещё одно поле.

Виноват ли наш гипотетический программист? Или может быть виноват "самый первый" программист - тот кто из одного диалога сделал два? Зачем он так сделал?

На самом деле, моё глубокое убеждение состоит в том что ни один программист тут не виноват. Исходное копирование функциональности могло быть вызвано массой разных, более или менее объективных причин - желанием перейти на новую более прогрессивную и интересную технологию, желанием исправить "неправильную"архитектуру и так далее. И естественно предполагалось "все написать по-новому". Просто не успели, не смогли, забыли, отложили на потом (конечно, бывают и ошибки программиста - "не знал" что такой диалог уже есть, но я их здесь не рассматриваю, поскольку по моему опыту это как раз довольно редкий случай).

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

Задача руководства как раз и состоит в том (не только в этом конечно), чтобы организовывать "переход" на новые технологии, архитектуры, отслеживать, чтобы все это доводилось до конца и чтобы на это хватало времени. А также для оценки необходимости самого этого перехода.

Поэтому в следующий раз, если увидите две разных реализации одного и того же не торопитесь ругать программиста.

Моя компания - Большой Брат?

Учёт времени сотрудников. Хорошая ли это вещь? У меня есть мнение...

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

Вот несколько примеров того, как система может быть устроена (примеры взяты отсюда):

• Задержка утреннего прибытия в офис на одну минуту карается написанием объяснительной записки с указанием причины опоздания.
  
• Три опоздания на одну минуту за месяц караются вычитанием оплаты за один полный рабочий день.
• У всех сотрудников каждые 15 секунд тайно делается снимок с экрана компьютера. Он сохраняется на сервере для просмотра руководством. Этот процесс невозможно прервать: компьютерная программа слежки, если ее отключить, запускается самостоятельно.
• Все присланное или отправленное с вашего компьютера по электронной почте сохраняется и полностью доступно для просмотра начальством. То же касается и пейджеров. Печатная корреспонденция вся просматривается руководством. Прочитав, начальник, если посчитает нужным, передаст ее тебе.
• Телефонные разговоры записываются и прослушиваются.
• Если в течение дня ты зафиксирован в столовой более чем два раза, тебя уже внесли в особый список, который докладывается наверх.
• Если работнику нужно покинуть офис более чем на час, необходимо заблаговременно, минимум за 2-3 дня, написать заявление и получить одобрение руководства.

Вот примерно такие системы. Вот и вопрос - оправдано ли введение таких систем, а если оправдано, то когда и в каких масштабах?

За

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

• Можно предположить что с введением системы штрафов за опоздания будет меньше опозданий
• Люди в рабочее время будут заниматься исключительно рабочими делами, поскольку они знают что бездельничать им не позволят
• Бесконечное время, которое можно было бы провести в "курилке" будет израсходовано на что-то нужное для компании
• Дисциплина - сама по себе вещь хорошая, а подобная система помогает воспитывать дисциплинированные кадры - любые указания всегда будут выполняться точно и в срок
  

Против

Против доводов не меньше. И это конечно в основном доводы сотрудников.

• Работники "творческих" профессий утверждают что они могут работать только тогда когда им творчество в голову ударяет :-), а не по расписанию
• Врачи утверждают что полноценно работать 8 часов подряд совершенно невозможно и так или иначе но человеку нужен отдых
• Иногда поесть ... или наоборот может захотеться лишний раз, совершенно не сообразуясь с расписанием компании
• Многим не нравится что им не доверяют на работе ( а что иное есть слежка, как не недоверие?)
• Люди часто считают, что нет смысла сидеть на работе если работа уже сделана - что если человеку хватает меньшего времени?
• Система тотального слежения слишком напоминает ужасные антиутопии типа "1984" или "Мы", в том числе и отношением к людям в этих антиутопиях. А к людям там относились как к материалу.
  

Выводы

Выводы трудно делать... Дело в том, что на самом деле, также как и во всех остальных случаях все слишком сильно зависит от ситуации.

Нужно ли в МакДональдсе поощрять "творческое" мышление сотрудников и разрешать им опаздывать на работу? Думаю не нужно. И честно говоря, думаю что и сотрудники МакДональдса (даже рядовые) с этим легко согласятся.

А правильно ли компании, производящей программное обеспечение пытаться построить из себя МакДональдс? Это большой вопрос. Пока что опыт известных мне компаний показывает, что из "конвейерной" системы хорошие люди очень быстро уходят, причём именно из-за некомфортных условий, связанных со слишком суровыми правилами. Самые успешные компании на рынке программного обеспечения - Microsoft и Google исповедуют совершенно другие принципы (можно почитать тут и тут) - и как видно у них неплохо получается.

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

Что в имени тебе моем?

Данный пост представляет собой кросс-пост отсюда и является ответом на вопрос в RSDN.

Вопрос:

Что-то я немного отстал от современных терминов. Я являюсь руководителем разработчиков в одной из компаний. В оффисе у нас в во-всю ходят термины: прожект менеджер, продакт менеджер, тим лидер, руководитель проекта, аналитик, архитектор и т.п.
Мог бы кто-нибудь мне разъяснить, в чем состоят функциональные обязанности вышеперечисленных ролей? Чем они отличаются? Может, есть где-то документ, регламентирующий обязанности этих ролей? Больше всего интересует, чем отличается продакт-менеджер от архитектора, так как передо мной стоит выбор одной из этих двух ролей...

Люди и Роли

На самом деле каждая компания сама придумывает названия. Нет единого стандарта.Поэтому
так и трудно найти что-то конкретное — в каждой организации по-своему понимаются эти термины. Некоторые методологии
разработки программного обеспечения (RUP, MSF) вводят свою терминологию, но она стандартизирована только
внутри самих этих методологий.

В итоге, в каждой компании, в которой хотят ввести такие роли/должности их вводят по принципу:

1. Какими методологиями пользовался/что изучал человек, который придумывает роли
2. Собственное понимание/перевод соответствующих английских терминов
   

Некоторые термины, тем не менее, имеют чёткое определение, которое дано им международными организациями. Например, что такое project, project management, определяется документом PMBOK (Project Management Body Of Knowledge), который можно назвать стандартным.

По этому документу:

Project — Временное предприятие, предназначенное для создания уникальных продуктов или услуг.
Здесь временное означает, что у проекта есть четко определенные начало и конец.
Уникальные продукты или услуги — означает что, то что будет создано, каким-то существенным образом отличается от того что уже есть.

Project Management — Использование знаний, навыков, методов, средств и технологий при выполнении проекта с целью достижения или превышения ожиданий участников проекта.

Project Manager — человек, осуществляющий project management.

Почти что как у Лема

«СЕПУЛЬКИ — важный элемент цивилизации ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКАРИИ».
Я последовал этому совету и прочёл:
«СЕПУЛЬКАРИИ — устройства для сепуления (см.)».
Я поискал «Сепуление»; там значилось:
«СЕПУЛЕНИЕ — занятие ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКИ».
Лем С. Звёздные дневники Ийона Тихого. Путешествие четырнадцатое.

В задачи Project Manager входит (опять же по PMBOK):

1. Создание и исполнение плана проекта
   
2. Создание календарного плана и контроль времени
   
3. Управление ресурсами проекта (людьми, оборудованием, помещениями)
   
4. Создание и управление бюджетом проекта (как денежным, так и временным)
   
5. Установка и поддержание стандартов качества
   
6. Взаимодействие с другими отделами компании, а также с контактами вне компании
   
7. Оценка и управление рисками проекта

Тем не менее, необходимо помнить, что в каждой конкретной организации сложилось свое понимание каждого термина, в том числе и для таких как "project management".

Личный взгляд

В моей голове тоже есть понимание того что означают все эти должности, и это понимание я здесь сейчас изложу.

• Project manager/руководитель проекта — мое понимание совпадает с тем, что изложено в PMBOK (приведено выше)
  Данная роль является "начальственной" в бюрократическом смысле слова. В конечном итоге, если не удается договориться,
  последнее слово всегда остаётся за руководителем проекта.
  
• Product Manager
  Отвечает за продукт с точки зрения заказчика. То есть product manager — это человек, представляющий заказчика в команде разработчиков. В обязанности Product Manager входит:
  
  
  1. Исследование рынка
  2. Выявление потенциально нужных заказчикам продуктов, сервисов, функциональности
  3. Исследование конкурентов (иногда этим занимаются специально выделенные люди)
  4. Маркетинговые исследования, PR акции, пресс-релизы (иногда эту работу делают специальные Product Marketing Manager, иногда она производится совместно этими двумя ролями)
  5. Выработка списка "features" продукта
  6. Определение приоритетности тех или иных "features" (что делать обязательно, что нет)
  7. Позиционирование продукта (на какой рынок продукт нацелен, портрет покупателя)
  8. План развития продукта (RoadMap)
  9. Ценообразование (сколько продукт будет стоить, какая будет модель лицензирования)
  10. Взаимодействие с высшим руководством компании, если таковое необходимо
  11. Взаимодействие с отделом продаж и совместная выработка стратегии продаж
      
  
  Все вышеизложенное взято из определений "product manager" в MSF, курсов Pragmatic Marketing,
  а также из собственного опыта и возможно ещё откуда-то (ну то есть в голове есть, а откуда взялось — не помню).
  
  Данная роль не является "начальственной", то есть product-manager-ы не могут никому приказать — их голос совещательный.
  
  
• Program Manager
  Это странная сущность, существование которой кажется мне не очень оправданным. В моей картине мира вполне можно обойтись без неё. Тем не менее, она существует и, по всей видимости, введена была в Microsoft
  ещё очень давно. Про эту роль есть два неплохих рассказа:
  
  
  1. Элдар Мусаев "Про маразм и Program Management"
  2. Steven Sinofsky — бывший руководитель группы разработки MS Office
     
  
  Данная роль не является "начальственной", то есть program manager-ы не могут никому приказать — их голос совещательный.
  
  
• Team Leader
  Team Leader — это руководитель небольшой группы программистов. Подчеркну TeamLeader — это начальник, в бюрократическом смысле этого слова. То есть он может приказать. И пусть никого не смущает слово leader. Под небольшой группой понимается группа в 1-5 человек (ну понятно что цифры приблизительные).
  
  
• Technical Leader
  Данная роль предполагает, что человек обладает некоторыми очень глубокими знаниями в каком-то техническом вопросе или теме — более глубокими чем все остальные. Это — "эксперт" в какой-то области. Областью может быть все что угодно: C++, ADSI или очень глубокое знание системы контроля за исходными текстами, использующейся в компании.
  В любом случае эта роль оказывается у человека в результате его "репутации" — в какой-то момент все понимают что этот человек действительно эксперт. Эта роль не является начальником в бюрократическом смысле этого слова, то есть никто не обязан подчиняться technical leader-у.
  
  
• Analyst
  Данная роль отвечает за исследование "процессов" для заказчика. Часто эта роль оказывается близкой к роли Product Manager, особенно если нужна разработка для какого-то одного конкретного заказчика.
  Также как и product manager-ы аналитики занимаются:
  
  
  1. Выявлением нужной заказчикам функциональности
  2. Составлением спецификаций и приоритезацией "features" продукта
  3. [иногда] Оценкой применимости тех или иных средств для реализации нужной функциональности (в MS, насколько я понимаю — это как раз часть деятельности Program Manager-ов)
     
  
  Данная роль не является "начальственной", то есть аналитики не могут никому приказать — их голос совещательный.
  
  
• Architect
  
  "I am the Architect"(C)Matrix Reloaded. Честно говоря я затрудняюсь здесь дать точное определение.
  Очень часто — это не роль, а состояние души
  
  Данная роль не является "начальственной", то есть архитекторы не могут никому приказать — их голос совещательный.

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

Несколько ссылок

1. Project Management Institute — авторы PMBOK
   
2. Российский портал управления проектами pmprofy — у них есть глоссарий с определениями

Опыт работы: зачем нужен С++?

Недавно составляли вакансию. Необходимо нанять человека, основным занятием которого будет написание пользовательского интерфейса при помощи C# и WPF. В черновике вакансии я написал, помимо всего прочего - опыт работы на C++ - от 2-х лет. При обсуждении требований сразу же возник вопрос: а причём тут собственно опыт работы на C++? Мы ведь проект пишем на C#! И С++ в нем в ближайшее время скорее всего не понадобится. Так зачем же в вакансии требовать опыт работы на C++, отсекая тем самым многих специалистов?

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

Дело в том, что опыт работы на C++ - это некоторый показатель опыта и уровня человека. Сразу оговорюсь - не таланта, способностей к программированию или "крутизны", а именно уровня.

C++ - трудный язык. Я бы даже сказал очень трудный. Мало кто из знакомых мне очень профессиональных программистов рискует сказать что он знает C++ идеально. Причём даже среди тех, кто действительно знает его очень и очень хорошо. Я сам тоже не рискую этого сказать. Это не так. C++ позволяет программисту сделать практически все, но за это требует от программиста внимательности, тщательности и довольно большого объёма работ.

Кроме того, C++ - это "чистый" язык, язык в котором нет "заточенности" на ту или иную библиотеку или стиль программирования. Много ли людей пишет на C#, не используя Framework Class Library? Много ли людей пишет на Java не пользуясь библиотеками от Sun? .NET Framework + C# и Java - это платформы, а не языки.

С++, в отличии от многих, не привязан ни к чему. Это дает программисту на С++ поразительное, я бы даже сказал, иногда угнетающее, количество возможностей и вариантов запрограммировать даже самое простое действие. Как прочитать строчку из файла на C#? 99% ответов, как мне кажется будет выглядеть примерно так:

Textreader tr = new StreamReader("file.txt");
Console.WriteLine(tr.ReadLine());
tr.Close();

А как сделать это в C++? Есть тысяча разных способов - функции Win32, семейства _open, семейства _fopen, функции MFC, ATL, boost, стандартной библиотеки, собственные "единственно верные" функции. 99% ответов будет наверное такими - надо посмотреть что используется в той программе которую мы пишем и постараться использовать то же самое.

С++, кроме того, поддерживает мультипарадигменное программирование, то есть возможность пользоваться при написании программ многими стилями программирования.

Все это приводит к тому, что программисту на С++ приходится много работать. Больше наверное, чем программисту на любом другом из широко распространённых нынче языков. Иногда это работа является рутинной, технической - С++ не освободит за нас выделенную память. Но при выполнении этой работы, программист понимает как должны быть устроены механизмы автоматического освобождения памяти. Программист проникает во внутренности, причём невольно - ему просто приходится, иначе программа не работает как положено. Программисту приходится разбираться во внутренностях работы функций операционной системы, других библиотек. Ему приходится понимать то как устроен экспорт функций в DLL И тысячу других вещей, которые программисту например на C# понимать не нужно. Но ведь бьют то все эти вещи по обоим! Пока что операционные системы написаны большей часть на C/C++.

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

Disclaimer:

1. Я понимаю что ассемблер в этом смысле ещё лучше чем С++. А машинные коды ещё лучше чем ассемблер. На самом деле строчку про опыт программирования на ассемблере я бы тоже вписал, только вот боюсь что это отсечёт слишком много кандидатов. А чувство меры терять тоже не следует.
   
2. Конечно, все вышесказанное не значит что кто на С++ не писал, тот "жизни не нюхал". И конечно есть огромное количество программистов, вполне квалифицированны и способных, но не имеющих опыта работы на C++. Просто помните - мы писали вакансию. Мы звали к себе незнакомого человека, и всего лишь пытались оценить его и уменьшить количество времени, проведённого на собеседованиях.
3. И наконец, я не считаю С++ лучше или хуже какого-либо из упомянутых или не упомянутых языков программирования. Я считаю, что С++ это ... как бы сказать, ну скажем как механическая коробка передач на автомобиле. Кто на механике ездил, тот сможет ездить на автомате очень легко. А вот обратное - верно не всегда. При этом, заметьте, на чем ездить лучше - вопрос не рассматривается.

Ну и напоследок. После того как я объяснил свою позицию, другой участник обсуждения текста вакансии сказал: "Да, мне тоже не очень нравится это предложение - опыт работы на С++ от 2-х лет ... не маловато ли?".

Оценка сроков

Почему большинстов проектов не укладываются в срок? Практически все известные методики оценки времени, которое будет затрачено на разработку проекта аппелируют к "экспертным" оценкам и к обратной связи.

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

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

Всегда, в процессе разработки, выясняется что исходное разбиение на задачи и подзадачи было не совсем верным. Что не приняли во внимание то-то и то-то. Что есть другой способ, который позволяет эту и эту подзадачи не делать, но требует сделать некую новую подзадачу и так далее. Все зависит от количества этих изменений. Если их слишком много, то проект в конце будет совершенно не похож на то, чем он являлся в начале. Обратная связь пропадает и не с чем оказывается сравнить первоначальные сроки. А значит говорить об рациональном, происходящем с "открытыми глазами" улучшении качества оценки собственной работы говорить не приходится. Если программист давал оценку, что для выполнения задач A, B и С ему потребуется месяц, то что ему дает знание о том что для выполнения задач D, E и F ему потребовалось полтора? Насколько точно были оценены A, B и С? это остается неизвестным. А значит, обратная связь становится "слабым" игроком, не очень помогающим в оценке будущих проектов.

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

[Карьерная] Лестница в небо

Добрый день,

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

Очень часто и в форумах, и просто в разговорах приходится обсуждать вопрос о том что кто-то там стал "Senior Developer", а кто-то даже "Team Lead", а некоторые вообще "Ахитекторами" ((с) Матрица). Тут же кто-то обязательно выскажется по поводу того, что формальные названия должностей не имеют значения, а важно что за человек и как он делает свою работу. И что уж лично он-то, ну тот который высказывается хоть и является простым программистом, но получает больше любого другого. Вот об этом и будет разговор.

Во всех фирмах, компаниях, организациях, конторах - называйте как хотите - существует штатное расписание. Иногда все красивые названия в нем прописаны, иногда (в основном по разного рода бухгалтерским соображениям) - нет. Что же там написано и зачем все это нужно? Я буду смотреть на вопрос НЕ с точки зрения конституции, трудового кодекса и бухгалтерии. Я буду смотреть на вопрос примерно так как вроде бы надо расследовать преступления - пытаясь ответить на вопрос "Кому это выгодно?".

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

Немного демагогии

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

1. Управленческий
   
   Ну то есть те, кто проявляет склонность к управлению людьми становятся начальниками небольших групп, потом больших групп, потом отделов и так далее. Их деятельность становится деятельностью управленческой.
   
   
2. Технический
   
   Это и есть собственно наша тема. Существует ли карьерный путь у людей, которые не хотят заниматься управлением другими людьми? Не хотят быть "начальниками" в классическом смысле этого слова?
   

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

С другой стороны, отсутствие подобного пути может стать серьёзной отталкивающей силой, поскольку часто бывает так что управленческие позиции уже заняты, а значит отсутствует ЛЮБАЯ возможность "карьерного" продвижения, чтобы в это понятие не вкладывалось.

Примеры

Рассмотрим теперь несколько примеров лестниц. Очень во многих фирмах есть специальные технические лестницы.

• В статье Fog Creek Compensation Joel Spolsky описывает техническую лестницу, которая существовала на тот момент в его компании Fog Creek Software.
  
  
• На самом деле, и в этом признается сам Joel, его система была позаимствована у компании Construx (основанной, кстати известным автором многих бестселлеров, посвященных программированию и управлению проектами, таких как Code Complete или Software Project Survival Guide ). В Construx есть собственная лестница, описанная подробно на web_сайте компании.
  

• Компания Microsoft также использует "лестницу" оценки разработчиков. К сожалению у меня нет информации про современное состояние их лестницы, но есть данные из замечательной книги Microsoft Secrets. Лестница состоит из 5 ступеней - начиная с 9 и 10 уровней для выпускников колледжей и заканчивая 15 уровенем, который получают только люди, чья высокая компетентность лично отмечена Биллом Гейтсом
  

Если вы решили не ходить по ссылкам, а дочитали до этого места, то я очень кратенько опишу вам все эти "лестницы". На самом деле они все (и ещё некоторые с которыми я знаком, но которые не опубликованы) примерно одинаковые. Итак:

1. Есть несколько уровней, у каждого уровня есть номер и известно какой уровень самый высшмй
2. Есть правила перехода с уровня на уровень. Иногда - это правила формальные (например - прочел такие-то книжки, сдал такой-то тест/экзамен), а иногда неформальные - например начальник взял да и сменил твой уровень по своим собственным соображениям.
3. Есть правила привязки уровня к зарплате/бонусу. Опять же, правила бывают разные, но они есть. Иногда правило может быть совсем формальным - то есть уровень участвует в расчете формулы зарплаты или бонуса как коэффициент где-то.

А зачем она нужна?

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

Внедренцы лестниц чаще всего мотивируют необходимость их наличия следующим:

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

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

1. Я работаю лучше всех, делаю всю работу, но платят мне меньше потому что я не успел прочитать какую-то книжку, которая требуется для перехода с уровня на уровень. Я читал другую книжку, которая в сто раз лучше этой, но это никого не волнует!
2. Начальство заводит любимчиков
3. Вот приняли только что человека - за что ему дали сразу более высокий уровень?

Мне кажется, карьерная лестница должна существовать, и в первую очередь потому что это отличная мотивация. Однако, для её успешного внедрения требуется как минимум:

• Внедрить "справедливые" и формализованные правила перехода с уровня на уровень.
• Внедрить методики оценки вновь приходящих сотрудников для их адекватного позиционирования по уровням
• Обязательно создать "лестницы" для не-разработчиков - тестировщиков, технических писателей и других специалистов. А также установить соответствие уровней в разных лестницах (например - 10 уровень разработчиков это примерно тоже, что 11 уровень тестировщиков). Кстати говоря, в Microsoft это сделано.
• Предусмотреть возможность смены правил перехода. Те, кто составляет критерии перехода - тоже совершают ошибки. Более того, технологии меняются, пишутся новые книги и так далее. Необходима возможность смена правил перехода с уровня на уровень
• Знать меру - не всегда те методики, что хороши для компаний в которых работают сотни человек, хороши для компаний где работают 10 человек. Не стоит позволять процессам и формальным методам подменять собой саму работу.
  

Про бонусы

Вступление
Очень часто последнее время попадаются вопросы и рассуждения на тему "бонусов". Нужны бонусы или нет, приносят ли они эффект или нет, привыкает ли человек к бонусам или нет, к каким "событиям" в жизни команды/проекта/коллектива стоит приурочивать бонусы и так далее.

Мне тоже охота порассуждать на эти и близкие к этим темы.

Только я хочу обсуждать не только денежные бонусы. Я хочу обсуждать все виды "подарков" которые компания может позволить себе выдавать людям. Все, кроме зарплаты.

А зачем все эти бонусы нужны

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

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

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

Ведь бонус, он только для того и нужен - чтобы добиться чего-то - не так ли? Если у всех работников будут общие цели, то их будет удобнее добиваться.

Типы бонусов

Бонусы, в моем понимании бывают нескольких типов:

1. Деньги
   
• определенный процент от зарплаты выплачиваемый в случае качественной работы в течение какого-то срока времени
  
• ежегодный денежный бонус к новому году/годовщине компании/ещё какому-то празднику
• премия по итогам работы над проектом
  
  
2. "Полезные для работника"
   
   
• оплата отпуска в далекой южной стране
• оплата абонемента в бассейна, фитнесс-клуб
• оплата обучения по специальности
• оплата поездки на выставку, семинар, конференцию
• оплата сдачи экзамена (например MS сертификации)
• медицинская страховка
  
  
3. "Приятные безделушки"
• В Microsoft, как известно, принято после успешно выпущенного продукта выдавать участникам проекта специальную награду "ShipIt!", о которой существую неоднозначные мнения.
  
  Вот например Элдар Мусаев очень даже доволен своей.
  
  А, например, автор знаменитой книги Microserfs Дуглас Коупленд, показал в ней
  далеко не самое хорошее отношение сотруников к этой награде:
  
  If you ship on time you get a Ship-It award: a 12-x-15-x-1- inch Lucite slab - but you have to pretend it's no big deal. Michael has a Ship-It award and we've tried various times to destroy it - blowtorching, throwing it off the veranda, dowsing it with acetone to dissolve it - nothing works. It's so permanent, it's frightening. (http://www.wired.com/wired/archive/2.01/microserfs_pr.html)
  
  
• Майки, футболки, толстовки с логотипом фирмы
• Значки, ручки и прочие сувениры
• Почетные дипломы и грамоты, звания "Лучшего сотрудника" года, месяца и тому подобное
• Благодарности, объявляемые публично в присутствии всех или многих сотрудников компании

Цели компании

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

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

Цели, как они представляются сотруднику

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

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

Заключение

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

Лояльность работников - взгляд со стороны менеджера “среднего” звена

Привет,

Сегодня вот решил записать теорию, появившуюся у меня некоторое время назад. Теория посвящена вопросу о том как удержать на работе нужных и талантливых сотрудников. Я не специалист, вполне возможно что эта теория совсем не нова, так что не обессудьте.

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

Именно об этом я и хочу поговорить. Естественно, я сразу же хочу заметить, что разговор пойдет исключительно о тех работниках, в которых вы, как начальство заинтересованы. Нет необходимости сохранять плохих работников - даже наоборот. Кроме того, не для любого вида деятельности “старый” (то есть опытный) работник лучше нового. Ну так такие виды деятельности я также исключаю из рассмотрения. Итак, как же создать такие условия, чтобы хорошие работники не увольнялись?

Внешние и внутренние силы

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

Короче говоря, внешние силы - это все что вне “нашей власти”. Под “нами” я имею ввиду компанию, отдел кадров и руководство которой хотят сохранить своих хороших работников. Основная идея состоит в том что внешние силы мы рассматривать не будем. Нет смысла - ведь все равно мы не сможем с ними ничего сделать. Кроме того, если внимательно к ним присмотреться - бывает не так уж и много ситуаций, когда мы действительно не можем, хотя бы косвенно повлиять на ситуацию. Работа - очень мощное средство влияния.

Мы будем рассматривать только внутренние силы. Внутренние силы - это все те силы, которые не являются внешними

Отталкивающие и притягивающие силы

Мне видится, что внутренние силы можно также разделить на два класса - притягивающие и отталкивающие.

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

Отталкивающие силы - это то что человеку на работе не нравится. На самом деле обычно это “перевернутые” притягивающие силы - маленькая зарплата, котороткие отпуска, плохие отношения в коллективе и так далее.

Баланс сил

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

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

Менеджер

Есть только один человек, который в состоянии решить эти вопросы - непосредственный начальник. Это есть одна из важнейших функций непосредственного начальника - определить что для его подчиненных является “притягивающим”, а что “отталкивающим” и постараться обеспечить баланс. Никто кроме него этого сделать просто не сможет, из-за того что недостаточно много общается с этими людьми. Если начальник эту функцию не выполняет - он не начальник(я ни в коем случае не говорю, что это единственная функция начальника). Наша работа и наши коллеги по работе - это место и люди с которыми мы проводим большую часть своей жизни. Мы возможно общаемся со своими семьями меньше чем с коллегами по работе. Начальник, который не обращает внимания на эти моменты - должен пересмотреть свой подход, если конечно он считает что “сохранность” людей - это хорошо.

А что если мое начальство не согласится со мной?

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

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

Но зато потом Вы сможете сказать себе что вы сами себя уважаете. А разве может быть что-то приятнее?

Делегировать или нет - вот в чем вопрос?

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

“Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить…Способность к делегированию - это одно из качеств, которое вы, лидер, должны постоянно совершенствовать” - Дж. Ханк Рейвотер - “Как пасти котов”, Питер, 2006

“Some swing a lot toward the technical and risk losing touch with their team and thereby building the wrong thing or missing their dates. Some swing toward the management, losing touch with the technology and losing the respect of their developers. Of the two, swinging too much toward the technology is the biggest danger, but only by a little.” Chris Sells, Microsoft Program manager.

“При большом объеме задач, явно не соответствующих вашей компетенции и стоимости вашего времени, подумайте о покупке внешней услуги - секретаря, технического помощника и.т.п” Глеб Архангельский. “Тайм-Драйв”

“Я убежден, что если делегирование руководства осуществляется правильно, то обе стороны только выиграют от этого и гораздо больший объем работы будет выполнен за гораздо меньшее время” Стивен Кови. Семь “Навыков высокоэффективных людей.”

И есть ещё тысяча и один довод за делегирование. Причем, хочу обратить ваше внимание, обычно предлагается делегировать работу рутинную, “не соответствующую вашей компетенции” , монотонную, не творческую и тому подобное. Вообще-то я с ними со всеми согласен - это здорово сбросить на менее оплачиваемых помощников рутину, а самому заниматься решением действительно творческих и интересных задач, справиться с которыми способен только твой гений :-).

Кроме того, делегирование - это способ масштабирования работ. Если все задачи проходят через одного человека, то в какой то момент этот человек становится “узким местом”, “бутылочным горлом” , на котором застревают все дела и вопросы. И делегирование, правда уже не рутинных задач, а руководства какими-то направлениями (вполне себе по Стивену Кови) - это вероятно единственный способ избегать бутылочного горла.

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

Делегирование - это не только разгрузка от рутинной работы и возможность “масштабирования” руководства. Это ещё и способ хорошенько забыть все, что ты когда-то умел делать. Эти самые рутинные задачи порождают в нас мысли о том , как их выполнение автоматизировать. Это постоянные мучения с системой контроля версий позволяют нам понимать почему её нужно поменять на другую ( уж извините - примеры будут из программирования, так как это область с которой я лучше знаком). Это жутко медленно выползающее окошко Output заставляет нас говорить о том , что компьютеры нужно поменять на новые. Мы можем видеть прогресс проекта, только если мы занимаемся рутиной.

Большая часть работы, которой мы занимаемся, программирования - это именно рутина. Продумать алгоритм, разработать сложную и элегантную архитектуру - это здорово и интересно, но львиную долю времени занимает не это. “Технические вопросы”, как многие “менеджеры” их называют , могут занимают существенно больше времени. Как правильно устроить структуру проекта в системе контроля версий? Как правильно хранить ресурсы, так чтобы их было удобно локализовать? А как можно осуществить мониторинг запуска процессов в Windows? А почему ошибка не правильно передается в ATL attributed проекте? Все эти и подобные им вопросы возникают очень часто и в большинстве случаев являются хорошими кандидатами на делегирование.

Вот только в результате - теряется “чувство” проекта. Долго, долго тебе кажется что ты все это знаешь и понимаешь, а когда в какой-то момент кто-то заболевает и тебе приходится слезть со своего менеджерского пьедестала и спуститься в окопы, то оказывается что ты все забыл! То есть теория-то вроде есть, а вот практика … с ней хуже. Все верно, многое вспоминается довольно быстро, но тем не менее.

Рутина - это тренировка! Тренировка для мозгов и для рук. У культуристов есть такая поговорка “Чтобы много жать - нужно много жать”. Мне кажется, она справедлива не только в спорте. Технический менеджер конечно же должен делегировать задачи, особенно в большом коллективе, иначе он станет узким местом. Но он ни в коем случае не должен совсем сбрасывать с себя “рутину”. Иначе он перестанет быть частью команды - он станет эдаким живым Excel-ем, который просто каждое утро опрашивает всех о состоянии дел и считает что он знает в каком состоянии находится проект.

Не делегируйте все! Знайте меру! Это тяжело, но необходимо.