Архив за Ноябрь, 2009

Предпроектная гигиена

Среда, Ноябрь 25th, 2009

Начну я с короткого экскурса в историю сестер милосердия .

Флоренс Найтингейл разработала собственный метод, который был максимально прост и максимально эффективен:

  • чистота,
  • свежий воздух,
  • хороший уход,
  • режим питания.

И все это начало творить настоящие чудеса.

 В октябре 1854, в период Крымской кампании, Флоренс вместе с 38 помощницами, среди которых были монахини и сестры милосердия, отправилась в полевые госпитали сначала в Скутари (Турция), а затем в Крым. Последовательно проводила в жизнь принципы санитарии и ухода за ранеными. В результате менее чем за шесть месяцев смертность в лазаретах снизилась с 42 до 2,2%.

 Википедия и http://www.marfa-ka.ru/publ/1-1-0-34

Я далек от мысли, что мне удастся сформулировать принципы, благодаря которым “смертность” проектов уменьшится до двух процентов. Но и в два раза было бы замечательно.

1. Нет концепции - нет проекта.

Перед проверкой наличия концепции из нее должны быть удалены обороты-паразиты: “очевидно”, “это нам почти ничего не стоит”, “сокрушительный успех”, “огромное значение для нас”, “развитие стратегического направления” и прочее. Если после этого от концепции осталось менее 50% - можно считать, что ее нет (нужно писать заново).

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

Что делать, если концепции нет, а проект запущен? Если вы болеете за судьбу фирмы, у вас есть следующие варианты: написать концепцию самому или  саботировать проект (шучу).

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

Что делать, если никто не умет писать концепцию? Это означает, что у вас нет человека, способного выполнять роль “Управляющий продуктом (product manager)”. А что будет, с софтверным проектом, если, например, у вас не найдется людей способных писать код? Загнется? Так без концепции он загнется еще вернее. Найдите того, кто умеет. Можно на работу по договору. Такие люди точно есть. Даже, как ни странно, в России. Я точно знаю, что есть. Я с ними даже общался.

2. Нельзя делать оценку трудоемкости до оценки прибыли.

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

Приведу аналогию со строительством. Для того чтобы оценить стоимость (осметить проект) нужно потратить 3% от стоимости проекта на осмечивание. И 15% до  этого на проектирование. Т.е. нужно потратить почти пятую часть бюджета только для того, чтобы узнать стоимость проекта. А грубо оценить продажи квартир в 300-квартирном доме на острове Пасхи можно. Стремятся к нулю. На острове Пасхи проживает всего 3,7 тысячи жителей.

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

Вредные советы.

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

PS. Вышеизложенное сформулировано под впечатлением статей Ашманова.

К борьбе с должностными инструкциями, будьте готовы

Суббота, Ноябрь 21st, 2009

По мотивам и в продолжении Менеджер по борьбе с персоналом., а так же в продолжении цикла статей Владислава Балина “Защита от темных исскуств

В некой фирме
Может даже UmaNetto.
Появился вдруг сотрудник
По борьбе работе с персоналом

Чтоб ценить не перестали
выпускает циркуляр он
что трудиться нынче нужно
лишь регламенту согласно.

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

Долго, нудно вычисляет
КТУ и KPI
Чтоб потом цифирь зарплатна
Была сразу всем понятна.

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

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

В январе к техническому писателю подошел маркетолог.

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

Февраль. Техпис остался без премии. К тестировщику подошел программист и спросил:

- Я слышал ты в прошлом проводил исследования на время отклика при разных вариантах организации деревьев в БД?
- Проводил. Но если я буду об этом рассказывать вместо тестирования, меня лишат премии.

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

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

- Программист. И что думаешь?
- Тестировщик. Да есть одна мысль. Поможешь?
- Не вопрос.
- Тогда иди, пиши письмо.

После тайной встречи всех заинтересованных лиц, начинает раскручиваться маховик корпоративной переписки.

От. Программиста
Кому. Руководителю разработки
Копия. Руководителю тестирования
Требуется помощь тестировщика <имярек> для принятия решения о выборе архитектуры.

От. Руководителя разработки
Кому. Руководителю тестирования
Копия. Программисту
Это позволило бы существенно сократить время проекта и уменьшило бы проектные риски.

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

1. Оставить как есть. Сроки проектов будут срываться, а проектные риски взлетят до небес. Полагаю, на то чтобы угробить фирму нам понадобится 6-12 месяцев.

2. Разрешим нарушение Инструкции конкретно в этом случае. Но подобные решения нам придется принимать по десятку раз в день. Что не очень эффективно.

3. Изменим инструкцию тестировщика. В связи с расширением должностных обязанностей, согласно  ТК РФ, увеличим оклад. И будем поступать так каждый раз, пока все не придет в норму.
4. Переоценим решение о зависимости зарплат и выполнении должностных инструкций. Техническому писателю принесем официальные извинения и  начислим январскую премию в феврале.
В хорошей фирме, способной исправлять последствия неправильных управленческих решений все будет хорошо. Может быть даже генеральный лишит квартальной и годовой премии сочинителя циркуляра за развал работы.

А в жизни бывает по разному. Очень по разному…

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

Здесь мерилом успеха считают усталость

Суббота, Ноябрь 21st, 2009
То, что ценим мы и любим, чем гордится коллектив.

- Мы крупная фирма, - произносится это с гордостью.
- У нас работает … сотен / тысяч сотрудников, – и нам есть чем годиться.

Я вот по своему, видимо, невежеству полагал, что крупность фирмы должна измеряться по среднегодовому проходу (продажи минус стоимость материалов), а не по числу занятых стульев. Не будем брать тех, кто занимается продажей техники или сидит на пилораме бюджета. Рассмотрим софтверные фирмы. От коллег я слышал и согласен с ними, что 100 миллионов долларов – это не крупная, а средняя фирма. Хотя таким оборотом действительно можно гордиться.

Чего я ни разу не слышал и это для меня удивительно, так это высказываний следующего типа:
Мы первая и пока единственная российская фирма, достигшая рубежа в $100 млн годового прохода при численности привлеченного персонала всего 150 человек. Таким образом, мы обогнали нашего ближайшего конкурента более, чем в три раза. У него было 700 человек при $150 миллионах.

Коллеги, я ошибаюсь или действительно в РФ не принято хвастать эффективностью фирмы?

Косвенная метрика уровня специалиста

Суббота, Ноябрь 14th, 2009

Какова высота стопки книг, которые вы прочитали? Измерять в метрах. Для ведущего инженера этот показатель видимо от пяти метров. Действительно прикинем. 20-50 книг двухсантиметровой толщины в год и так 8-12 лет. Статьи, наверное, тоже можно как-то учитывать. Но 1000 статей на страницу не заменят одной книги на 300 страниц. Хотя и дополнят ее. Так что минимум половину высоты стопки должны составлять книги. И естественно часть литературы должна быть по смежным темам.

Трудозатраты на тестирование

Четверг, Ноябрь 12th, 2009

Эту статью я начал писать, когда мне предложили принять участие в опросе про соотношение программистов и тестировщиков. Я решил дождаться результатов и стелать развернутый анализ.
(more…)