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

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

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

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

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

Из докладов мне особенно понравились следующие:

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


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


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


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


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


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

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

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

All you need is ... ЛАФ.

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

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

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

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

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

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

Также доступно видео семинара:

Водопады

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

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

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

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

 

На первый взгляд вроде бы все хорошо:

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

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

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

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

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

Причин тому несколько:

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

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

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

В конечном итоге это приводит к смерти продукта и запуску разработки нового.

Scrum Fundamentals Certified

На выходных сдал экзамен на сертификат Scrum Fundamentals от PMStudy.

Экзамен был довольно простой, подготовка заняла примерно три недели и состояла, в основном, в чтении Scrum Book of Knowledge и немного дополнительно wikipedia по Методу освоенного объема, а также о NPV, IRR и т.п..

А вот и сам сертификат:

Краткие рекомендации по оценке проектов

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

Хочу сказать большое спасибо всем, кто пришел!
По моему присутствовало человек около 40.

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

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

Также доступно видео семинара:






Хочу также сказать большое спасибо Анатолию Суздальцеву и Юлии Ериной за помощь в подготовке семинара!

Почему нельзя позволять заказчикам проводить интервью с сотрудниками подрядчика

Последние пару лет я замечаю все более набирающую популярность тенденцию среди заказчиков изучать резюме и проводить собеседования среди сотрудников подрядчиков.

Обычно заказчики объясняют это желание снизить свои риски относительно качества результатов проекта, сроков и т.п.

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

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

И часто в итоге это приводит к негативным последствиям.

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

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

Как с  этим бороться?
Простого ответа я пока для себя не нашел, но вот какие основные мысли зафиксировал, которые помогают в работе.

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

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

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

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

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

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