Успех любой системы (технической или организационной) заключается в простоте и прозрачности принципов ее функционирования.

Успех любой системы (технической или организационной) заключается в простоте и прозрачности принципов ее функционирования. 


Фраза не моя, фраза банальна, и она правильная на все 100%.


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


А чтобы протестировать их решение по очень простому принципу - можешь непротиворечиво объяснить зачем что нужно и на каких основаниях сделано? Если можешь - решение рабочее. Хотя бы потому что все косяки и нелогичности сразу видны. 

Малая автоматизация через Аутлук: Регламент учета выполняемых работ группы

Регламент учета выполняемых работ группы Х

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

Целью регламентации является повышение качества выполняемых работ и снижения рисков «пропадания/забывания» требований или договоренностей.

Решаемые задачи:

·         Создание простого механизма учета работ и требований заказчика с сохранением сложившихся правил проведения работ и взаимодействия.

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

·         Снижение рисков потери информации при смене исполнителя работ

Топ 10 вопросов будущему начальнику или руководителю проекта

Мой "топ" вопросов в менеджера выглядит так:
1 блок вижн отдела

• На чем отдел/проект зарабатывает деньги?
• Кто наши заказчики?
• Кто наши смежники\подрядчики?
• Какие можете озвучить планы по росту отдела/ срокам окончания проекта (если сингл проект)/ пулу потенциальных проектов

2-й блок вижн производственых отношений 

• За что я отвечаю? Какова моя ответственность?
• Какие еще ключевые позиции в проекте\отделе? Как я им подчинен?
• Как организована работа (скрам, канбан, прожект, джира, матрица и....) Каким образом учитываются трудозатраты/построена отчетность?

Облачная free Канбан-доска

http://kanbantool.com/

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

На планерках все кипятком писают и думают я их вручную рисую -)

Пишем ТЗ: Что такое Назначение Системы, Цели и Задачи

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

Очень часто когда обычных ИТ-шников просят написать VISION на систему на них сходит ступор. С чего начать? Особенно если вас просят начать с ТЗ по ГОСТ34 -). А оно начинается с Назначение, Цели и Задачи. А есть еще Показатели назначения, о которых рекомендуется не писать вообще.  По первой я то же не сразу приобрел легкость бытия, но регулярно встречаю различные перлы на эту тему. Приступим:

Рекомендации по оформлению писем

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

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

Собственно простые нехитрые правила (немного в мою специфику, но общий принцип думаю - универсален:

1. 1.       Тема письма должна содержать Название программы, название региона или его столицу краткое (Татарстан, Коми, Чита и тп)
2. 2.       Письмо должно быть адресовано исполнителю (запрос) или заказчику работы (ответ), одному человеку. Если пишите нескольким людям, необходимо в письме персонально указать от кого что требуется.
3. 3.       Если вам что-то нужно от адресата, это что-то должно быть выражено ясным требованием (прошу запросить регион, ожидаю ответа, и тп)
4. 4.       Если вы ставите задачу и результаты работ требуется выслать кому-нибудь кроме вас, требуется это указывать явно
5. 5.       Если вы запрашиваете информацию или отчитываетесь по нескольким позициям – позиции желательно нумеровать, чтобы в последствии ссылаться на них
6. 6.       Ставить Руководителя группы в копию
7. 7.       Хранить свою переписку
8. 8.       Если постановка задачи неясна – корректно запросить детализацию задачи

Библиотека - Рецензии

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

[b][i]Для себя я эту книгу поместил в категорию - "Почему я не прочитал ее три года назад". Как и следующую...[/i][/b]

Кьелл Нордстрем и Йонас Риддерстрале "Бизнес в стиле фанк"
----------------------------------------------------------
Затрудняюсь сказать о чем книга -) Формально, это трындеж о том что мир изменился и о том куда он изменился.
Книга не содержит кейсов, правил, доказательств и тп. Но прочитав ее я заразился уверенностью, что SCRAM, Google, разработка по требованию, работа с командой это именно то, что соответствует 21 века.
Рекомендую книгу в первую очередь "старым коням" и сбежавшим от монструозных корпораций советского типа. Осторожно, может изменить точку сборки -)

Патрик Ленсиони "Смерть от совещаний"
-------------------------------------
Еще один бизнес роман на 150 страниц. Как организовать правильное совещание и 4-е типа правильных совещаний.
А также бонусом темная сторона силы - как развалить любое совещание.
Рекомендую - всем

Элияху Голдрат "Цель: Процесс непрерывного совершенствования"
-------------------------------------------------------------
Первая книга о теории ограничений. И опять бизнес роман.
Чтобы понять о чем книга, нужно ее прочитать. И несмотря что в ней описывается машиностроительный завод, принципы ограничений никуда не деваются и в ИТ.
Рекомендую в первую очередь не менеджерам проектов, рекомендую - начальникам отделов и департаментов, людям которые организовывают работу на постоянной основе множества людей.