Тезисы третьей встречи (построение команд)

Встреча состоялась 4 июня, в первом корпусе СГАУ и была посвящена построению команд и отношениям фирма-сотрудник. Участники встречи: Калугин Александр, Константин Быченков, Денис Журавлев, Игорь Степин, Александр Сергеев, Андрей Чернов, Денис Пушкин,Николай Глумов, Артем Попов, Александр Белов, Ольга Белова.

 

Построение команды

Команду можно построить или на основе основе собранных людей (Есть люди — решаем кто, что будет делать) или на основе четко прописанных ролей (Сначала строим ролевую модель и потом подбираем под нее людей).

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


Роли исполняют
Часто в успешной команде участник застревает в своей роли и не растет профессионально. Выход их «вилки» когда хочется и команду сохранить и рост обеспечить — создание мини-команд в рамках организации. Участники команды мотивируются с помощью крепких связей и могут в то же время расти. Решение вопросов управления командами и выстраивания отношений между организацией и сотрудниками может взять на себя проектный офис. Наличие метрик и зрелых процессов позволяет зрелым организациям сравнивать эффективность различных команд.


Модель корабля для описания команды
Успех команды корабля — во взаимодействии исполнителей четко определенных ролей. Каждый кто хорошо выполняет свою роль — хорошо чувствует себя «на корабле». Так как отношения ролей, по построению, часто являются конфликтными (тестировщики и разработчики) личные отношения могут мешать эффективной команде. Когда люди меняют часто роли от проекта к проекту — получается команда на уровне фирмы.
Был полнят вопрос о профессиональном росте. С одной стороны сотрудники не очень то любят менять роли. Одновременно, мало кто видит себя в роли разработчика до пенсии. Работает ли модель waterfall в карьерном развитии или нет? Повышение квалификации — это осваивание новых ролей или совершенствование в чем-то одном?


Место команды в коллективе
Если коллектив сплоченный, то нельзя создавать команды под проект, а потом забывать про них. Фирма, которая дорастает до определенной точки перестает быть «семьей» для своих сотрудников. Появляется ядро фирмы и его окружение. Вне ядра ищутся подходящие роли. Переход от семьи к ролям часто болезненный. Можно попытаться совместить и семейный и ролевой подходы. При уходе от семейной модели необходимо формирование линейных отделов и матричная организация существования фирмы. Новичков надо вводить в семью постепенно, ведя вокруг них совместную деятельность.


Подходы к работе с командой
На длительный проект (от 6 месяцев) надо набирать взаимодополняющих и взаимозаменяемых людей по квалификации и моральным качествам. Сплачивает команду или общая цель или общий враг. Если команда небольшая (до 5 человек) то управляемость достигается ежедневными планерками и документированием «для начальства». Качество работы сотрудников регулярно (несколько раз в неделю) тестируются. Если метрики не устраивают — надо что то решать. При управлении коллективом исходить надо из того, что любой сотрудник может уйти хоть завтра. Поэтому необходимо дублирование исполнителей определенных ролей и должностные инструкции. Должностная инструкция необходима не только для улаживания трудовых вопросов но и для решения возможных юридических коллизий. Роли должны описываться в должностных инструкциях как можно полнее. Понятно, что описать все невозможно и в компании-семье должностные инструкции могут восприниматься как давление и ограничение «исконных свобод».


Влияние зарплаты на мотивацию сотрудников
Мотивация работника — авторская. Она состоит из гонорара, признания и интересной работы. Причем признание не надо путать с «хорошим коллективом». Присутствующие перечислили подходы к оплате труда, принятые в их фирмах: премиально-окладная, окладная и сдельная системы. Мотивация деньгами — конечный ресурс. Деньгами мотивируют тогда, когда больше нечем мотивировать. Помимо денежной мотивации возможна также мотивация признанием, условиями труда, гибким графиком.

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


Развитие и контроль специалистов внутри фирмы
В современных условиях практически невозможно привлечь готового специалиста. Приходится выращивать своих. Но все таки приток готовых специалистов извне крайне желателен хотя бы в малых дозах для того, чтобы приносить в коллектив альтернативный взгляд на задачи и другой стиль мышления. Если выращивать специалистов внутри фирмы, то до состояния «отстаньте от меня» пройдет довольно много времени, пока специалиста придется плотно контролировать.
Контроль можно осуществлять путем отчетов о выполненной работе и регулярных «инспекций». Возможны так же коллективные инспекции и презентации проделанной работы. Отчеты нужны просто потому что в команде от 7 человек уже трудно обсудить со всеми их планы. Практика детальных отчетов о выполненной работе в сформировавшейся команде практически всегда вводится с трудом.

Четвертая встреча. Место проведения

Четвертая встреча "Общение с заказчиком на первоначальном этапе" пройдет в офисе Mercury Development по адресу ул. Авроры, д 110, к.1. оф. 225.


Напоминаю, что встреча состоится в понедельник, 13 июня, в 12.00 

Четвертая встреча. "Общение с заказчиком на первоначальном этапе"

Андрей Чернов предложил в рамках 4-ой встречи провести игру-разбор кейсов на тему "Общение с заказчиком на первоначальном этапе".

Как правильно заинтересовать в проекте заказчика? На что следует обратить внимание при первой предварительной оценке трудоемкости? Что должен включать предварительный план работ?

Мне кажется – тема очень интересная, и с нетерпением жду 13 июня, когда всё это действо развернется… Начало в 12 часов. Осталось только определиться с местом.

Тезисы второй встречи (работа с требованиями)

В этой заметке -- несколько запоздалые тезисы второй встречи самарского "профсоюза ПМ-ов"

Встреча состоялась 22 мая, в офисе Mercury Development и была посвящена работе с требованиями. Участники встречи: Калугин Александр, Константин Быченков, Игорь Степин, Константин Иванов, Александр Сергеев, Андрей Чернов, Денис Пушкин, Андрей Суббота, Зиннур Темербеков, Анастасия Печкурова.

Первая часть встречи прошла в формате круглого стола. Участниками были высказаны обсуждены несколько вопросов управления требованиями. Во второй части А.Калугин (то есть я :) ) рассказывал о работе с нефункциональными требованиями (по мотивам ReqLabs’2011).

Итак, тезисы первой части:

1. Работать с требованиями необходимо на всех этапах проектах. В зависимости от стадии проекта – приоритеты различных требований могут меняться (одни требования могут становиться более приортетными – другие постепенно терять свой вес). При этом работа с функциональными и нефункциональными требованиями принципиально не отличается.

2. Требования не всегда позволяют достичь удовлетворенности заказчика

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

Да, в описанной ситуации – очевидная проблема с глубиной и полнотой сбора требований, но иногда заказчик может просто сказать – мне ваше видение это всё фигня, и мне надо вот так как я хочу… И как бы требования не формализовались – это может не помочь

А раз так – нужны ли вообще формализованные требования?

3. Обсуждение необходимости формальных требований
В процессе обсуждения необходимости формализованных требований были высказаны следующие мнения:

• Формальные требования нужны, чтобы сделать первый вариант продукта, который «не понравится»
• С точки зрения разработчиков – намного проще и удобнее работать с формализованными требованиями. С точки зрения заказчика или Product Owner-а – ситуация обратная: есть идея и наброски и дизайн – и давайте сделаем чтобы было хорошо.
• Заказчику и Product Owner-у, у которых есть идея – детальные формальные требования не интересны, им интереснее чтобы на основе минимальной информации команда смогла создать рабочий прототип, на основании которого – двигаться дальше
• Требования – это линия, по одну сторону которой находится команда разработки, а по другую – заказчик. Причем с точки зрения команды – требования должны быть стабильны; с точки зрения заказчика – ему интереснее их постоянно менять и дорабатывать.
• Даже если заказчик понимает, что формализованные требования нужны -- постепенно ему становится скучно с ними работать.
• Разработчики и QA влюблены в требования – и они счастливы, когда они формализованы. Наличие формализованной согласованной спецификации – на деле не спасает от изменения требований. Но по крайней они хоть как-то помогают.
• Так как заказчику требования это не очень удобны -- формат описания требования необходимо согласовывать с заказчиком – чтобы ему было удобнее с ними работать.
• Формализация требований должна включать критерии приемки продукта на высоком уровне, чтобы задавать хоть какие-то правила игры, даже без детализации конкретных требований.
• Несмотря на то, что формализованные требования необходимы для успеха проекта, их отсутствие – это скорее проблема разработчика, а не заказчика.
• Техническое задание/спецификация требований, если будет фиксировать требования в том, виде в котором их готов формулировать заказчик – будет очень неровной, так как различные требования будут иметь различный уровень детализации. Поэтому при формализации требований – необходимо концентрироваться на ключевых моментах. Например, спецификация должна содержать набор функций продукта, возможно без детального описания отдельных функций.
• Проблема набора функций в том, что список функций никак не отражает принципиальные нефункциональные требования к тому, как эти функции должны быть реализованы. Даже если минорные модификации функции можно пережить, дополнительное нефункциональное требование – может повлечь полную переработку системы.
• Формализация требований должна быть на нескольких уровнях. При этом необходимо стараться сделать так, чтобы вероятность изменения требований более высокого уровня была как можно меньше.
• На этапе заключения контракта чаще всего фиксируется прототип требований – который призван демонстрировать что заказчик и разработчик в общем говорят на одном языке и обе стороны в принципе ожидают, что этот прототип будет изменяться. Этого уровня детализации может быть достаточно, чтобы достичь соглашения.
• Формализация требований необходима как можно глубже. Но есть проблема связанная с тем, что если требования формализуются до заключения контракта – то работа про их детальной проработке может быть проведена впустую.
• Формальные требования помогают разрешать недопонимания и конфликты между командами тестирования и разработчиков.
• Формальные требования – позволяют продолжить отношения разработчика и заказчика после реализации функциональности, специфицированной этими требованиями.
• Способ, уровень, подход к формализации требований зависит от контракта между разработчиком и заказчиком. Если проект состоит из «мини-фаз» размером с неделю, то в такой ситуации – формальное описание требований может быть излишним – так как объем требований на неделю – небольшой.
• В договор с заказчиком можно закладывать возможность модификации требований заказчиком в процессе разработки. А раз так – то уровень формализации – может быть менее жестким. Всё зависит от позиции разработчика и тут есть две альтернативы: «дискаунтеры» -- когда только то что явно описано входит в scope – остальное за доп плату – тогда фиксация требований должна быть очень жесткой. Или “luxury” – когда прямая противоположность.
• Для модели «дискаунтера» формальные требования необходимы, но есть специфика приоритета того что должно быть в требованиях: требования должны формально и жестко фиксировать внешние границы проекта. Внутри этих границ – обычно изменения требований не столь критичны.
• Отдельный интерес представляют собой контракты между заказчиком и исполнителем – в которых исполнитель является экспертом очень высокого уровня. В такой ситуации – фактически исполнителю дается зеленый свет на реализацию функциональности тем методом, каким он это видит. В такой ситуации фиксация требования необходима только на уровне бизнес-целей проекта.
• Необходимо понимать в каком виде происходит формализация требований – чтобы ответить на вопрос, нужны ли формальные требования. В общем виде ответ на вопрос – да. Но видом формализации может быть, например, просто аудиозапись разговора с заказчиком – или детально проработанное ТЗ.
• Даже если требования между заказчиком и компанией-разработчиком не формализованы – до разрабочиков и тестировщиков – требования должны доходить в формальнизованном виде.

3. Участники обсудили необходимость учета возможности изменения требований в процессе разработки на уровне контракта с заказчиком:

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

4. Требования с точки зрения команды: как работать с требованиями, чтобы не было стресса для команды.

С точки зрения разработчика – две основные причины стресса, связанные с требованиями это:
a. полное изменение видение – что редко.
b. неполнота спецификации -- отсутствие в ней архитектурной информации об особенностях реализации – а так как спецификация уже подписана – то никто не берет на себя ответственность за внесение изменений в эту спецификацию.

Спецификация, по которой договорились аналитики и заказчик – может быть всё равно не содержать информации о том, как реализовывать отдельные требования с точки зрения команды-разработки или с точки зрения команды тестирования. Одним из возможных способов решения проблемы стрессовости спецификации – это совместная работа над спецификацией представителей различных ролей – что дополнительные расходы.

Однако, на практике получается так, что привлечение всех ролей к разработке спецификации на проекте – всё равно необходимо делать. А раз так, то чем раньше это будет сделано, тем лучше.

Например, команда должна привлекаться на этапе выявления бизнес-цели. При этом можно дать разработчикам возможность общаться с заказчиком – задавая им вопросы и выявляя детали. Задача ПМ-а при этом построить этот процесс взаимодействия команды разработки с командой заказчика.

ВСЁ!!!

Аудио записи

Проводится голосование среди участников сообщества: необходимо ли выкладывать необработанные аудио-записи встреч? Просьба высказывать свое мнение в комментариях.

Встреча #4

Встреча #4 состоится в понедельник, 13 июня, ориентировочно в 12.00. Место встречи и тема -- уточняются. Принимаются предложения и пожелания в комментариях к этой заметке.

Третья встреча. Новая тема

В силу молчаливого согласия большинства, тема третьей встречи изменилась.
По инициативе К.Быченкова, новая тема:

"Построение команды. переход от рабочей группы к команде".

Еще раз всем напоминаю о необходимости послать письмо на samarapmgroup@gmail.com c заявкой на участие. Пропускной режим с СГАУ -- это вам не хухры-мухры...