четверг, 18 августа 2016 г. - www.msmirnov.ru

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

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

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

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

А теперь обещанные примеры-наблюдения.

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

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

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

    Какой был найден выход: договориться с тестировщиками о том, чтобы они не давали формальный ход высоко-приоритетным багам, а сообщали о них неформально.

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

    Какой был найден выход: закрывать недочеты как "Не баг".

    Результат: низкой качество работы с требованиями.
  • В компании Г решили депремировать специалистов тех.поддержи за большие задержки в ответах на запросы клиентов.

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

    Результат: низкое качество обслуживания клиентов.

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

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

среда, 10 августа 2016 г. - www.msmirnov.ru

Концепция развития персонала ИТ-компании

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

Вот они:
  1. На рынке наблюдается острая нехватка специалистов по всем направлениям - разработчики, тестировщики, аналитики, тимлиды, руководители проектов.
  2. Постоянно растущее многообразие технологий приводит к тому, что сейчас практически каждый новый проект предполагает освоение командой какой-то новой технологии.
  3. Проектов на рынке много, больше чем людей, которые способны их качественно реализовать.
  4. ВУЗы готовят специалистов с сильным академическим уклоном, при этом у них страдает подготовка по более "практическим" направлениям.
  5. ВУЗы заинтересованы в интеграции с работодателями, но эта заинтересованность, как правило, продвигается отдельными энтузиастами, общей системы нет. В целом работодатели и ВУЗы дезинтегрированы.
  6. Большинство ИТ-специалистов хотят учиться и развиваться и им следует обеспечить такую возможность.
  7. Обучение и развитие специалистов должно идти согласованно с производством, чтобы с одной стороны обеспечить закрепление полученных знаний на практике, а с другой стороны гарантировать обучение именно в тех направлениях, в которых нуждается производство.
  8. Сотрудники являются основной ценностью ИТ-компании, ее основным конкурентным преимуществом, наряду с производственными процессами.

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

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



Направления
Методы
Инструменты
Подбор
Профили (модели) компетенций

Методы оценки компетенций кандидатов

Кадровый резерв

Работа с учебными заведениями
1. Студенческая практика
2. Преподавание в учебных заведениях
3. Знакомство со студентами старших курсов
4. Проведение олимпиад и конкурсов
Хантинг сотрудников

Мониторинг рынка труда

Внутренний подбор

Отслеживание карьеры ушедших сотрудников

Адаптация
Welcome-треннинг
План адаптации
Формулирование зон ближайшего развитиия
Беседа с сотрудником, его руководителем, сохранение результатов во внутренней системе
Наставничество

Помощь в поиске жилья

Оценка результатов прохождения испытательного срока

Ведение и развитие
Выявление личных мотивов сотрудников
1. Сохранение особенностей личных мотивов сотрудников по внутренней учетной системе
2. Формулирование зон ближайшего развития
Категоризация персонала
1. Принципы категоризации персонала
2. Присвоение категорий
3. Сохранение категорий сотрудников по внутренней учетной системе
Ежеквартальные цели сотрудников
1. Формулирование целей сотрудников совместно с их непосредственным руководителем
2. Сохранение текущих во внутренней учетной системе
3. Анализ результатов достижения целей
4. Сохранение истории целей во внутренней учетной системе
Периодическая оценка сотрудников
1. Автоматизированная оценка через опросы во внутренней учетной системе
2. Автоматическое присвоение категории сотруднику
3. Сохранение истории результатов оценок по сотруднику во внутренней учетной системе
Анализ изменения оценок сотрудников

Обучение сотрудников
1. Внутренее обучение
2. Внешнее обучение
3. Сертификация
4. Наставничество
Матрица компетенций
1. Формирование списка технологий и компетенций
2. Оценка сотрудников по знакомству с технологиями
3. Сохранение матрицы компетенций и ее истории во внутренней учетной системе
4. Внутренний подбор сотрудников на основе имеющихся компетенций для новых проектов
Периодический анализ потребностей компании

Профили (модели) компетенций

Ротация сотрудников

Выведение
Интервью на выходе
Беседа
Анализ результатов трудоустройства ушедших сотрудников

Мой сайт - www.msmirnov.ru

вторник, 2 августа 2016 г. - www.msmirnov.ru

UML - быстрый старт. Теперь можно скачать бесплатно в формате pdf.

Давным давно, 8 лет назад, я поместил в свой блог короткую методичку "UML - Быстрый старт", которую я использовал для обучения сотрудников языку UML.

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

Я решил оформить методичку в виде PDF-документа, так чтобы кто угодно мог скачать ее и пользоваться.



Методичка доступа для загрузки по следующей ссылке:
http://www.msmirnov.ru/public/UML_quick_start.pdf

Мой сайт - www.msmirnov.ru

суббота, 23 июля 2016 г. - www.msmirnov.ru

Метрики проектного офиса

Около года назад я писал заметку KPI проектного офиса, посвященную основным показателям, которые я снимал с производственного процесса.

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

Метрики теперь у меня идут не сплошным списком, а сгруппированы.

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

Метрики по проектам:

  • Плановые
    • Плановая дата старта проекта
    • Плановая дата окончания проекта
    • Плановые трудозатраты по проекту - суммарный плановый объем трудозатрат в человеко-часах (есть также и другие плановые затраты, но у меня они бывают очень редко)
    • Плановая стоимость проекта (для клиента)
    • Плановая длительность проекта - в днях
  • Фактические
    • Фактические трудозатраты по проекту - суммарный фактический объем трудозатрат в человеко-часах
    • Фактическая дата старта проекта
    • Фактическая дата окончания проекта
    • Фактическая длительность проекта - в днях
  • Аналитические
    • Объем трудозатрат, потраченных на выполнение гарантийных обязательств -
      - считается как объем трудозатрат, потраченных на гарантийный багофикс после закрытия проекта.
    • Длительность выполнения гарантийных обязательств - в днях
    • Эффективная почасовая ставка - получается при делении стоимости проекта на объем фактических трудозатрат в часах. Сравнивая эффективную почасовую ставку различных проектов можно сделать вывод о том, какой из них был более эффективным с точки зрения зарабатывания денег.


 Метрики по руководителям проектов и программам:
  • Средняя ошибка в оценке объемов проектов, в процентах, в динамике.
    Анализируя динамику изменения данного показателя можно делать вывод об изменениях качества попадания в рамки с течением времени. Чем меньше становится ошибка, тем лучше.
  • Средняя ошибка в оценке сроков проектов, в процентах, в динамике.
    Анализ аналогичен предыдущему пункту.
  • Средняя длительность гарантийного багофикса, в процентах и в днях, в динамике.
    Анализ изменения данного показателя позволяет оценить динамику изменения качества результатов проектов.
  • Средняя доля гарантийного багофикса в общем объеме трудозатрат проектов, в процентах, в динамике.
    Анализ аналогичен предыдущему пункту.
  • Количество закрытых проектов.
    Информация об интенсивности работы производства.
  • Количество текущих проектов.
    Аналогично предыдущему.
  • Количество проектов на гарантии.
    Анализ позволяет понять насколько велик риск возможного отвлечения рабочих групп на работы, не приносящие непосредственной прибыли.
  • Количество проектов, потребовавших гарантийных исправлений.
    Можно использовать как показатель качества работы команды.

Метрики по проектному офису и по портфелю проектов:
  • Количество текущих проектов и клиентов
    Информация об интенсивности работы производства.
  • Распределение трудозатрат по проектам и клиентам.
    Показатель степени диверсификации производства. 
    Чем более равномерное распределение имеется - тем лучше.
  • Распределение трудозатрат по типам оплаты проектов.
    Я выделяю три вида оплаты проектов - Fix Price, Time-and-material и Бесплатно. Доля бесплатных проектов, как не приносящих прибыли, желательна к снижению.
    Доля Fix Price-проектов, как более рискованных по отношению к Time-and-material, тоже предпочтительна к снижению.
    Соответственно, доля Time-and-material-проектов предпочтительна к увеличению.
  • Коэффициент утилизации сотрудников - отношение кол-ва часов, отработанных всеми сотрудниками на прибыльных проектах к доступному кол-ву часов.
    Анализ причин снижения данного коэффициента помогает выявить и устранить причины простоев, перераспределить сотрудников между группами, избавиться от неэффективных направлений и т.п.
  • Средняя эффективная почасовая ставка - средняя сумма прибыли, приходящаяся на одного сотрудника в час. Изменение данного показателя говорит об изменении общей эффективности производства.

По сотрудникам:
  • Сумма заработанных средств - рассчитывается по всем проектам, в которых сотрудник принял участие. В Time-and-material-проектах рассчитывается исходя из почасовой ставки, по которой выставляется счет за данного сотрудника в данном проекте. В Fix Price-проектах рассчитывается исходя из эффективной почасовой ставки на проекте.
  • Количество отработанных часов.
  • Средняя эффективная почасовая ставка - рассчитывается как отношение суммы заработанных средств к количеству отработанных часов.

    Анализ изменений и их причин для данных показателей по сотрудникам помогает избавиться от простоев, организовать эффективное распределение сотрудников по проектам и т.п.
Мой сайт - www.msmirnov.ru

воскресенье, 19 июня 2016 г. - www.msmirnov.ru

Летний Аналитический Фестиваль-2016 (ЛАФ-2016)

Вот и закончился 7-й Летний Аналитический Фестиваль-2016 - моя любимая IT-конференция.

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

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

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

Из докладов мне особенно понравились следующие:
  1. Макс Гапонов "User Story Canvas" - отличное пошаговое руководство для начинающего аналитика для описания User Story

  2. Сергей Рассамакин "Борьба за доверие Заказчика. Почему её надо вести? Как её надо вести?"

  3. Дмитрий Безуглый "Гибкий бизнес и системный анализ"

  4. Юля Ерина "Выявление и оценка компетенций аналитиков"

  5. Круглый стол Дмитрия Безуглого "Уровень зрелости процессов постановки задачи"

  6. Круглый стол Ани Абрамовой "Нужно ли продавать бизнес-анализ"

Большое спасибо всем организаторам и участникам фестиваля!

Увидимся в следующем году!

All you need is ... ЛАФ.

P.S. И как всегда, немного фоток.







Мой сайт - www.msmirnov.ru

понедельник, 6 июня 2016 г. - www.msmirnov.ru

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

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

Содержание доклада:
1. Основные термины
2. Основные этапы жизненного цикла любых проектов
3. Waterfall
4. RUP
5. Agile
- Экстремальное программирование
- Scrum
- Kanban
6. Метод освоенного объема

Уровень доклада - для начинающих и для среднего уровня.

Презентация доклада доступна здесь:
http://www.msmirnov.ru/public/processes.pptx

Также доступно видео семинара:
Мой сайт - www.msmirnov.ru

четверг, 2 июня 2016 г. - www.msmirnov.ru

Водопады

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

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

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

Т.е. используется небольшой водопадный процесс (waterfall) для реализации изменений.



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

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

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

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

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

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

В конечном итоге это приводит к смерти продукта и запуску разработки нового.
Мой сайт - www.msmirnov.ru