вторник, 30 августа 2011 г.

Управление проектами - если у вас все работают по домам

Я как менеджер немного недолюбливаю когда програмисты работают дома. А то как -)
Сталинская шарашка - голубая мечта розового ПМа. Все всегда на месте, в одном помещении и дополнительный стакан сметаны для мотивации... Но, слава богу, сейчас другие времена.

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


То есть или все в офисе, или все дома. Смешанный вариант очень накладно, потому что вам придется в проекте поддерживать не один производственный процесс, а 3-и:

  1. работа с надомниками
  2. работа с офисниками
  3. интеграция результатов первых со вторыми -)

Почему возникают проблемы интеграции? Потому что в разных группах разные каналы коммуникации. Следовательно:

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

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

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

пятница, 26 августа 2011 г.

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

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

Этот пост начинался как ответ на простой вопрос "Как построить и наладить процесс обучения команды тестировщиков из 6 человек?", но потом сформировался в отдельную статью.

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

четверг, 25 августа 2011 г.

Пишем Техническое задание. Общие сведения

Общие сведения идут в ТЗ под номером 1

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

Казалось бы ничего сложного. Но есть ньюансы -)

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

Я использую для 3-х последних пунктов магическую фразу следующего вида -  Порядок и объем финансирования работ/сдачи работ/и тп определяется договорными материалами между Заказчиком и Исполнителем.

Вторая порция ньюансов связана с перечнем документов на основании которых проводятся работы. Надо сказать что не стоит сюда вставлять, что попало (для этого есть раздел "источники разработки"). В принципе достаточно сюда воткнуть ссылку на договор по которому вы делаете проект. И все. В крупных конторах можно дополнительно притянуть - План капитальных затрат (если в нем есть пункт выделения денег на ваш проект), какое-либо распоряжение о проведении работ\проекта. Главное правило - документ должны быть реальными и утвержденными с указанием даты утверждения. Различные концепции, целевые программы, типовые проекты вносятся в другой раздел.

Третий ньюанс. В первом пункте укажите после краткого названия системы в скобках (далее - Система). Это позволит вам во всех своих документах и проектах именовать Систему однообразно и позволит избежать ошибки копипаста. Ну или можно использовать подставляемые поля Ворда.

Инструменты начальника отдела. Учет рабочего времени

Рекомендую для учета рабочего времени вот этот инструмент Grindstone

Из преимуществ:
Простой инструмент
Не облако
Можно вводить задним числом
Записи о расходе времени вносятся из списка задаваемых работ
информативный отчет который можно выгрузить в таблицу и сразу отослать начальству -)

среда, 17 августа 2011 г.

Инструменты начальника отдела. Партизанский Канбан

Начать с того, что мне очень нравится Канбан. Я считаю данный инструмент наилучшим из "at glance" для использования в качестве "градусника" проекта. Повышение температуры под сидалищем ПМа он показывает точно, да и лишен самообмана Проджекта с % завершения задач.

Но попытки внедрить доску в отделе наткнулись на следующие тривиальные грабли:

Пишем Техническое задание. Описание объектов автоматизации

2.5. В разделе «Характеристики объекта автоматизации» приводят:

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

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

Я использую следующий общий подход по его написанию:

вторник, 2 августа 2011 г.

Пишем Техническое задание. Показатели назначения

Показатели назначения... Одна из самых мутных статей ГОСТа.
В самом госте требования к содержанию Показателей мутны и непонятны. Вот посмотрите:
В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы ее назначению.

    Но что тут надо писать реально, история умалчивает. Я встречал разные альтернативные мнения и подходы из которых можно выделить 3-и: