Еще раз о принципах ведения журнала проекта

В продолжении вот этого

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

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

Универсальный сценарий разговора с сотрудником который подходит и начинает что-то втирать

Универсальный сценарий разговора с сотрудником который подходит и начинает что-то втирать
1. Является ли это проблемой?
2. Почему это проблема? (В чем состоит собственно проблема)
3. Почему это случилось? (чистое незамутненное ИМХО сотрудника)
4. Что можно предпринять? (для решения проблемы)
5. Что нужно предпринять? (для решения проблемы - ИМХО сотрудника)

И уже после этого начальственное решение - Молодец. И вот это попробуйте...
И чекпоинт в органайзер - проверить справился или нет

Шпаргалка руководителя - 10 главных приемов общения

10 главных приемов из книг по психологии, взято 

Простые правила работ. Типовое письмо о начале работ

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

• Уважаемый ФИО, перешлите мне список ваших серверов и баз данных. Инженер такой-то, Компания такая-то

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

И он совершенно прав.
Что бы избежать такой реакции и последующих перепихиваний в стиле "Он не ответил" - "Я ни чего не получал" достаточно первое письмо, независимо от того, что ПМ уже сто раз со всеми познакомился начинать каждый новый этап-подэтап-итерацию общения с формулировки следующего содержания:

• ИО, добрый день.
• Мне поручено провести ХХХ работы по проекту ХХХ
• Ваши контакты и информацию, что вы ответственный по данной задаче  мне передал ПМ
• Если вы не являетесь ответственным или считаете это письмо не по адресу, прошу сообщить мне об этом
• В ходе проекта запланированы работы по разработке ХХХХ
• Прошу ………

И Заказчики потянутся к вам -)

Мозговые карты - как их использовать

Очень краткий пост -)
Большинство знает что такое Mind Map.  Это "at glance" на знание.
Многие их используют.
Кто-то (например я) переводит в этот формат важные и полезные материалы. Например умные книги, ГОСТы, всякие ОРД и регламенты.

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

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

зы. в планшете это у меня конечно же есть то же -)

Как надо проектировать систему мониторинга

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

Проектировать систему мониторинга можно 2-я способами:
1. Расписать сколько серверов вы ставите, куда ставите агентов, накатить штатные шаблоны и оставить клиента с полученной спам-машиной один-на-один. Нехай мучается
2. Разработать инженерную модель управляемого объекта и настроить систему мониторинга в соответствии с полученными результатами.

Чем хорош первый вариант? Простотой! Думать не надо. Деньги зарабатываем на лицензиях.
Чем плох? У всех более менее крупных заказчиков этот фокус проворачивали пару раз как минимум. И очень большая конкуренция. И надо быть партнером вендора...

Чем плох второй вариант? Думать надо! Нужны спецы в предметной области. Нужно писать скрипты как минимум. Заказчик не готов за это платить или не хочет.
Чем хорош? Практически нет конкуренции. Нет капитальных и логистических затрат. Если вы влазите в проект и грамотного его делаете, то можно легко перейти на сопровождение и постоянный доход. Вас могут начать приглашать на аутсорс систем управлений.

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

Что должно входить в документацию на АС. Часть 2.

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

Итак - а кому нужна вообще документация? Ведь первый повод отказа от документирования - звучит именно так: "Ее все равно никто не будет читать кроме автора!"

Правила хорошего документа

Что отличает правильно написанный тех документ?
То же что и выступление хорошего политика - яркость, лаконичность, простота.

(рекомендую к прочтению - Карстен Бредемайер "Черная риторика", Альпина паблишер". 
Не менее 2/3 разговорных приемов можно и нужно использовать при подготовке документов)

Итак хороший документ должен быть:

1. Гармоничным. Хорошая и понятная структура изложения. Четкая рубрикация. Информация должна быть там "где ее ожидают".

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

3. Делайте "паузы" в документах. Разбивайте документ на разделы. Абзац не больше 10 строк. Раздел не больше 3-5-и страниц. Если в разделе должна быть большая спецификация, код, таблица - отправьте в приложение.

4. Тщательно взвешивайте необходимость объяснений и комментариев. Изложенные проектные факты будут выглядеть менее убедительно и более сложны для понимания, если вы будете описывать их во всех деталях. Если же описать детали надо, то изложите факты, а потом их детализируйте. Или переносите их в другие документы и приложения, специально для этих целей предназначенные.

5. Фокусируйте внимание читателя  на основных положениях документа, не разбавляйте их пустопорожним описанием. Или следуйте п.4

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

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

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