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

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

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

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

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

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

Ключи к успеху

Нашел в интернете интересную картинку.
Основные комментарии - "бедные думают неправильно. Думайте как богатые и станете ими"

А я вот подумал, что картинка верная, но по другому.

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

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

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

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

Пишем ТРП: Технико-экономические показатели

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

Я по наивности считал, и до сих пор считаю -), экономические показатели это TCO, ROI и тп подобное...

Но все проще:

Манифест - Сделано

Наткнулся совершенно случайно на Манифест - Сделано
Этот манифест был составлен Бре Петтисом в соавторстве с Кио Старком. Он содержит в себе тринадцать коротких пунктов, потому что на его составление было выделено всего двадцать минут. 

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

1. Есть три стадии бытия: незнание, действие и завершение.
2. Примите то, что все является черновиком. Это помогает завершить задание.
3. Стадии редактирования не существует.
4. Представить себе будто вы знаете, что делаете, это почти то же самое, что и действительно знать. Поэтому просто примите то, что вы знаете, что делаете, даже если это совсем не так.
5. Блокируйте прокрастинацию. Если вы ждете больше недели идею, которая поможет вам завершить задание, откажитесь от него.
6. Смысл завершения состоит не в том, чтобы закончить что-то, а в том, чтобы другие дела были сделаны.
7. Как только вы закончили что-то, можете сразу же выбросить это из головы.
8. Смейтесь над перфекционизмом. Это скучно и это отдаляет вас от завершения задания.
9. Люди с чистыми руками не правы. Делайте что-то, что сделает вас правыми.
10. Неудачи тоже считаются как «сделано». Делайте ошибки.
11. Разрушение — это еще один вариант завершения.
12. Если у вас есть идея и вы опубликовали ее в internet — это считается призраком «Сделано».
13. Завершение — это двигатель прогресса.

Шутка юмора

Отличную мысль подсмотрел на http://it-boost.com/dreamteam

Почти всем не важно быть на первом месте, и почти всем – очень важно не быть на последнем или предпоследнем


Какой вывод можно из этого сделать - в более менее большой команде необходим 

• штатный "задрот"
• задротная позиция
• задротные обязанности 

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

Цен еще не знаю, но судя по тех возможностям - прямой "убывец" HP Service Manager и BMC Remedy ITSM Suite.

Хотя конечно Axapta не убила SAP.

Зачем ограничивать себя границами? Маркерная стена это круто

Искал маркерную пленку, а нашел вот это. Маркерная краска.

Рекомендую всем в офисе. если АХО уломаете.

Вот теперь у меня мысли покрасить в коридоре стену. Для рисования.

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

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

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

Пишем ТЗ: Требования по сохранности информации

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

---

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

---

Если вам не требуется сохранять информацию с  нулевой потерей, то чтобы не напрягаться, следует написать что-то подобного вида:

Каталог публичных "Каталогов ИТ услуг"

В блоге нашел список публичных Каталогов ИТ услуг.
Если вы занимаетесь ITILом то очень рекомендую, по крайней мере как образец демонстрации  ихнего подхода вашему "тупому" заказчику. Особенно когда он играет в "микроменеджмент" и "полное покрытие"

Пишем ТЗ: Требования к надежности

Этот раздел на вой взгляд самый не нужный в современных АС общего назначения, то есть 90-а% всех АС разрабатываемых сейчас.

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

Интересный вопрос.
Сколько людей, столько мнений. В ГОСТ34 этих документов 2-е страницы -).
И хотя у меня 4-е выделенных человека описывают проектные решения я его, ГОСТ, не поддерживаю.

По моему мнению документация на АС должна содержать только документы востребованные для:
1. обязательно - Эксплуатации
2. необязательно - Сопровождения

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

Пишем документацию: Функциональная схема

Описание функциональности АС (П2, ПД и тп) неплохо будет проиллюстрировать картинкой - Схемой функциональной структуры.

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

• описать состав функциональных подсистем
• описать состав входящей информации
• описать состав исходящей информации
• описать схему информационных потоков

Схема достаточно просто делается и для меня в том числе является реальным инструментом проектирования. Схемка включает следующие элементы:

• квадратики изображающие функциональные подсистемы (например для сервисдеск системы: подсистема управления инцидентами; подсистема справочников, подсистема КБД, подсистема SLA).
• стрелочки входящие в квадратик подсистемы извне (от других АС или людей)
• стрелочки исходящие из квадратика подсистемы вовне (к другим АС или людям)
• стрелочки между квадратиками подсистем

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

Чорт! Совершенно не понимаю как у других хватает времени так много и красиво писать в блогах.

Как удержать в голове структуру документов

Как удержать в голове требуемую структуру документов?
Например требования к структуре ТЗ, ПД и других ДДЗ?
В самом простом пакете документов которые мы передаем заказчику содержится около 12 документов. Хорошо если я более менее помню ГОСт. Но структура может меняться. И забываться.

В качестве справочника я использую вот что:

1. перевел в формат мозговой карты РД50
2. распечатал в формате "один документ - один лист"
3. переплел в альбом и постоянно держу под рукой

Получилось, что-то типа такого - Ссылка

Ну если есть желание могу поделится исходниками -)

ТРП - Структурная схема системы

С чего мы начинаем выбор квартиры - с двух схем: 1) Карты района; 2) Плана квартиры.

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

Я использую всего 3. А видел много -). Итак:

1. Структурная схема
2. Функциональная схема (расскажу позже)
3. Схема автоматизации бизнес\технологического процесса (если он есть) (аналогично)

Структурная схема

Я не считаю, что Джобс был иноватором и, что тем более, он изменил мир.

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

Вот Гейтс изменил мир, а Джобс - нет.

Хотя, может время покажет, и окажется, что Джобс то же приложил руки к изменению мира, но не в приборчиках на которые все молятся, а на саму идею "юзабилити в квадрате".
Может быть воодушевленные успехом Джобса, топ менеджеры поймут простую идею - подавляющее удобство использования стоит пары лет работы и потраченных денег. Может быть они перестанут делать УГ?

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

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

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

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

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

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

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

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

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

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

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

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

Как не забыть "откуда ноги растут". Управление внешними нефункциональными требованиями

При разработке проектов практически всегда есть так называемые "внешние нефункциональные требования". Для меня они в первую очередь представляют из себя различные Приказы и Положения уровня предприятия. В первую очередь различные Концепции и Программы по основным положениям архитектуры предприятия и Приказы на тему обеспечения ИБ,
Фишка заключается в том, что при разработке проекта, эти требования надо учитывать и  постоянно ссылаться по тексту.

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

Я для себя со временем я выработал достаточно простой подход:

• все документы определяющие общие требования уровня предприятия хранить в одной папке
• в начале каждого файла добавлять пустую страничку в которую кратко помечать "в этом пункте обоснование этого"

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правильный шаблон презентации предложения на модернизацию

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

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

Итак подход к презентации решения с позиции решения проблем заказчика...

iServer

Интересно, как бы мог выглядеть сервер если бы его выпустила Apple?

Наткнулся на интересный ресурс - Журнал "Путь-Наверх" http://www.put-naverh.ru, журнал о повышении личной эффективности как я понял. Счас изучаю, есть ли что полезное. 

Мое управление собой или GTD для начальника отдела с расширениями

Я достаточно долго шел к управлению собой (листочки, блокнотики, Аутлуук, Лидер Таск...) и когда практически устаканил свою практику - перешел в менеджеры, а потом и в руководители... И практику пришлось дорабатывать.

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

Правила коммуникаций

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

Если не хотите - пришлите файл "Мои предложения или дополнения" 

EXIN открыло публичный доступ к части своих книг

http://www.exin-library.com/library.php
Входите, регистрируетесь и читаете-)

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


Как вы думаете, что здесь неправильно?

HR'ы явление для России новое, современное, и не профессиональное. В отличии от хэдхантинга -) Большинство эйчаров - это молоденькие девочки, которые работают в отрасли не более 10 лет и сваливают из темы уже в тридцатник.

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

Строптивый архитектор Заказчика

Интересный вопрос поднял Сергей Бережной в Строптивый архитектор

Я то же там отметился -)

"Да, ситуация действительно сложная.
Сам попадал в схожие ситуации.


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


НО! не как более технически лучший -), а как компромиссный по стоимости/рискам/времени разработки


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


В теории я всегда стараюсь встретится лично с архитектором и попытаться договорится - твое решение ууууух, но мы не успеем/видим риски/ТВОЙ проект провалится/ и по нарастающей от похвалы к лести. 


В любом случае рекомендую обратить внимание на такой инструмент как на координационный комитет с вопросом не архитектуры, а увеличения денег и сроков. Что бы не играть на поле архитектора и перейти на поле СЕО."

Кратко о том чем я занимаюсь

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

Я еще здесь

я никуда не пропал, просто тиражирую проект на надцать регионов.

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

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


Фраза не моя, фраза банальна, и она правильная на все 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-е типа правильных совещаний.
А также бонусом темная сторона силы - как развалить любое совещание.
Рекомендую - всем

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

Идеальная CRM или управление взаимоотношениями с тещей

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

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

Управление девушками и потенциальными тещами - не может не внести ажиотаж в процесс обучения. Я явно запомниться вместе с брендом вашей компании -)

у дураков мысли сходятся


Только начал думать как бы мне провести пилот поэфективнее, как нашел людей, которые уже давно так делают -) http://mainthing.ru/ru/item/445/
Они даже дальше пошли - они не пилоты делают, они тренинги приближенные к пилоту предлагают. И это правильно.

Жаль что 3-а года назад, когда я начинал внедрять системы ITSM\ITIL мне такие мысли в голову не приходили.  

Как продать пилот за деньги

На воркшопе "Профессиональная работа с людьми" от Панкратова&Орлова (http://www.it4business.ru/edu/2482/) от Дмитрия Коткина (http://www.espadas.ru/content/kotkin-dmitrii-sergeevich) услышал отличный пример аргументации.

Если вас убеждают, что этот пилот надо делать бесплатно или за маленькие деньки, то конечно не надо отказывать. Надо порадоваться и сказать что-то типа - "Отлично, давайте я вам его вообще сделаю бесплатно. У меня как раз есть пара студентов стажеров, которым нужна практика и которые просто горят поработать..." 

Пресейл. Бережливое производство

Казалось бы простой вопрос - "Зачем нужен пилотный проект вашему заказчику?"
Но если следовать принципу бережливого производства - ответ совсем не очевиден

Цель пилотного проекта - это предоставить в минимум времени максимум информации для ответа на  вопрос - "Применима ли данная технология/платформа у условиях моего бизнеса?". Это консалтинг бэби.

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