Планирование распределения сотрудников между проектами

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

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

Проблема решалась в следующих условиях:

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

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

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

Слева в матрице перечислены все сотрудники компании, сверху - клиенты (или проекты).

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

Справа (в колонке Итого) выполняется автоматический подсчет суммарной загрузки сотрудника.
Если сумма загрузки равно 100%, то считается что загрузка сотрудника запланирована успешно и поле подсвечивается зелены цветом.
Если сумма загрузки равно 0%, то это означает что у сотрудника нет задач и поле подсвечивается красным цветом.
Если сумма загрузки больше 0 и меньше 100, то это значит что сотрудник простаивает часть времени и поле подсвечивается желтым цветом.

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

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

Внизу таблицы приводится суммарная загрузка сотрудников по проекту либо клиенту.

Это позволяет оценить степень диверсификации компании - на приведенной ниже круговой диаграмме видно, как распределены ресурсы компании между проектами

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

Такой простой инструмент позволил через некоторое время решить текущие проблемы:

• Полностью избавиться от простоев
• Устранить понятие "безхозный" сотрудник
• Отобразить степень диверсификации

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

Программа адаптации новых разработчиков и тестировщиков

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

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

Если кому-то интересны конкретные разделы, то можно сразу посмотреть разделы

• План вхождения в должность для разработчиков 
• План вхождения в должность  для тестировщиков 

-  ниже в этой статье

Программа адаптации новых сотрудников

Общие положения

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

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

Данную программу должны знать и использовать в своей работе:
⦁    Генеральный директор;
⦁    Руководители проектов
⦁    Наставниками принятых сотрудников;
⦁    Менеджер по персоналу

Содержание программы адаптации

 

1.    Организационный этап 

Обеспечение комфортным рабочим местом нового сотрудника.

• Формирование заявки на мебель.
  Ответственный – завхоз.
• Формирование заявки на компьютер и т.д.
  Ответственный – системный администратор.

2.    Корпоративная адаптация

Вводная ориентационная беседа. Ответственный - HR

Предполагает формирование общего представления о компании, ее основных проектах,
Для того чтобы начать работать эффективно, человеку необходимо получить ответы на вопросы, связанные с организацией деятельности компании, например:
⦁    История развития.
⦁    Какое место занимает компания на рынке? Как идут дела? К чему стремится?
⦁    Каковы стратегические цели и приоритеты компании?
⦁    Кто является ключевыми клиентами, партнерами? Кто основными конкурентами?
⦁    Как осуществляется управление компанией? Кто принимает решения?
⦁    Какова структура компании? Руководство?
⦁    Разграничение полномочий, порядок выработки решений.
⦁    Какова периодичность и технология планирования и отчетности?
⦁    Какие действуют процедуры, регламенты?
⦁    Кто и в каком порядке подписывает документы?
⦁    Основные проекты и их содержание
⦁    Внутренние связи компании.

3.    Организационная адаптация

Оформление приема, копии документов (паспорт, СНИЛС, справки и т.п.)
Ответственный: HR
⦁    Показ основных помещений офиса.
⦁    Где находится туалет?
⦁    Где можно курить?
⦁    Где можно обедать, время обеда.
⦁    Кому сообщать о болезни?
⦁    Сколько дней, можно болеть без больничного, как оплачивается?
⦁    К кому обращаться, если в офисе холодно?
⦁    Где можно разместить свои вещи?
⦁    Стандартный налоговый вычет на ребенка?
⦁    Как оплачиваются и согласовываются счета?
⦁    Когда будет отпуск? С кем его согласовывают? Как оформить отпуск?  Существует ли график отпусков?
⦁    Учебный отпуск? Как оплачивается?
⦁    Как оформляется, оплачивается командировка?
⦁    К кому обращаться за справками 2НДФЛ в какое время.
⦁    Кто настроить компьютер?
⦁    Когда и где выдают зарплату?
⦁    К кому обращаться по поводу неисправностей в компьютере?
⦁    Как и когда здесь пьют чай / кофе? Можно ли принести свою кружку? Можно ли пить кофе на рабочем месте?
⦁    Как заказать канцелярию, курьера, машину, переговорную комнату?
⦁    Как принято справлять дни рождения? Сколько сдавать на подарки и кому?
⦁    Во сколько принято уходить домой? Можно ли утром опаздывать?
⦁    Кто заказывает воду, чай с собой покупают?
⦁    Как оплачиваются переработки?

4.    Социальная адаптация

Личное ознакомление с фирмой и ее сотрудниками. (Возможно, предварительное визуальное знакомство в соц. сети)

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

Ответственный: HR.

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

5.    Техническая адаптация

Ответственный: HR + системный администратор

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

6.    Профессиональная адаптация  

Ориентационное собеседование с непосредственным руководителем.
Ответственный:   Руководитель проекта. 

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

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

7.    План вхождения в должность

Ответственный: непосредственный руководитель

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

План вхождения в должность для разработчиков:

⦁    Изучение шаблонов проектирования GoF.
Прохождение внутреннего экзамена по шаблонам проектирования.
⦁    Ознакомление со стандартом кодирования C#
⦁    Ознакомление со стандартом кодирования SQL
⦁    Прохождение сертификации по .NET, Java либо MS SQL
⦁    Подготовка и проведение одного семинара по своему прошлому опыту либо какой-либо новой технологии.

План вхождения в должность  для тестировщиков

⦁    Изучение книги Сэма Канера "Тестирование программного обеспечения"
⦁    Изучение какого либо баг трекере - Jira, Redmine и т.п.
⦁    Изучение testlink или другой системы управления тест кейсами
⦁    Изучение материалов сертификации по тестированию ISTQB

Назначение наставника. 

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

Шаблон проектного предложения

Мне довольно часто приходит готовить проектные предложения для вновь поступающих заявок на проекты, поэтому я решил зафиксировать свои наработки в плане формирования проектных предложений.
Делаю это для себя (чтобы в будущем было всегда под рукой) и для всех, кому это будет полезно.
Здесь я описываю шаблон проектного предложения, который у меня сложился за последнее время и который я использую в своей работе.
Данный шаблон можно скачать по следующей ссылке: project_proposal.dotx
Кроме того, я добавил его в набор шаблонов, описанных в моей статье: Шаблоны некоторых документов для разработки проектов

А теперь сам шаблон (без разбивки по страницам и без фирменного стиля, которым он должен обладать):

Проектное предложение

<Название проекта>

1.    Название проекта.
<Официальное название проекта>

2.    Заказчик проекта.
<Официальное название заказчика проекта>

3.    Менеджер проекта.
<Имя менеджера проекта>

4.    Команда проекта
<Перечисление участников команды проекта>

5.    Цели проекта.
<Описание целей проекта>

6.    Поставляемые результаты проекта.
<Перечисление «осязаемых» результатов проекта, по наличию и качеству которых можно будет судить о завершении проекта. Можно также указать граничные сроки.>

7.    Предлагаемая технология.
<Краткое описание предлагаемых изменений.>

8.    Оценочный график проекта.
<Базовый план-график проекта в разбивке по фазам.>

9.    Оценочные ресурсы проекта.
9.1.    Первоначальная оценка трудозатрат на разработку:  <Бюджет проекта>
9.2.    Тип бюджета проекта: <Fix Price/Time-and-material/комбинированный>
9.3.    ПО: <Перечень и стоимость дополнительного ПО>
9.4.    Оборудование: <Перечень и стоимость дополнительного оборудования>
9.5.    Затраты на обучение и последующую поддержку: <Оценка трудозатрат>

10.    Ссылки.
<Ссылки на документы, использованные при оценке проекта.>

11.    Риски проекта.
<Описание рисков проекта.>

12.    Контакты.
12.1.    Руководитель проекта: 
12.2.    Руководитель проектного офиса:
12.3.    Генеральный директор:

ЛАФ-2015

Только что завершился первый день Летнего Аналитического Фестиваля-2015 (6-й по счету).
Я был очень рад видеть завсегдатаев фестиваля, с многими из которых мы уже стали добрыми друзьями.
ЛАФ для меня - это всегда глоток свежего воздуха среди рабочей суеты.

Программа конференции описана здесь: http://conf.uml2.ru/program2015
Наиболее интересными сегодня мне показались два доклада:

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

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

P.S. Хочу сказать спасибо Полине Смирновой за интересную компанию и беседу.

Как теряются знания в матричной стуктуре

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Как генеральные IT-подрядчики сбивают цены

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

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

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

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


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


4. При рассмотрении проектного предложения от субподрядчика требуется разбивка стоимости по работам внутри проекта и ролям, необходимым для выполнения этих работ.
   При изучении состава работ ставится под сомнение необходимость привлечения тех или иных специалистов, а также их плановые трудозатраты.
   В результате уступок со стороны субподрядчика цена здесь также сбивается, а субподрядчик при этом, идя на эти уступки, все равно остается ответственным за свою финальную оценку проекта и будет обязан оплатить превышение бюджета из своего кармана, если такое будет иметь место.
   Здесь осуществляется умелое лавирование между принципами Fix Price и Time-and-Material - опять же с целью сбить цену.
   Оценка идет по принципу Time-and-Material, оплата по Fix Price.  


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


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

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

Концепция автоматизированной системы управления физическим размещением данных на MS SQL Server

В этом материале я хочу рассказать о принципиальной структуре и концепции системы управления физическим расположением данных, построенной на базе MS SQL Server.
Данную концепцию можно использовать при наличии задачи построения системы подобного рода. Я надеюсь, что материал окажется полезным тем, кто сам столкнется с такой тематикой. Если по прочтении статьи у кого-либо появится потребность в более детальном рассмотрении тех или иных вопросов построения такой системы, я буду рад это сделать.

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

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

Структуру такой системы можно изобразить на диаграмме:

Как видно на диаграмме, система разделена на 4 части:

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

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


Задачи подсистемы "Интерфейс администрирования".

1. Позволять регистрировать в системе новые типы данных, определять их структуру (имена атрибутов, их типы и другие свойства).
2. Регистрировать в системе новые физические сервера для размещения данных
3. Задавать настройки расположение данных на каждом сервере
4. Управлять настройками распределения данных между серверами
5. Управлять настройками прав доступа

Задачи подсистемы "Управление расположением".

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

Задачи подсистемы безопасности.

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

Задачи подсистемы API.

1. Выдавать конечным потребителям данные, хранящиеся в системе
2. Принимать от потребителей новые данные, которые необходимо поместить в систему
3. Получать от потребителей сигналы о необходимости выполнения публикации переданных данных
4. Обеспечение параллельной работы пользователей с системой

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