В общем, ссылка на классную презентацию хорошего человека, Павла Алферова:

http://www.slideshare.net/slideshow/embed_code/35566734

Проектное упраление и опыт.

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

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

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

В общем, пользуйтесь - буду рад, если кому-нибудь она поможет.

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

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

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

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

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

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

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

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

Дальше имеет смысл расписать требования к формам и дизайну. Требования к формам, в идеале - это выделение критически важной информации длдя процесса, с анализом - когда, кто и в каком объеме поставляет нужную информацию. Требования к дизайну тут получаются вроде бы как не очень логичны... но логичны, потому что важно не только то, что будет нести форма в себе - но и то, как она будет выглядеть. Хотя требования к дизайну можно вообще поставить в конец ТЗ, или сделать ссылку на brandbook - тут вариантов масса.

Следующее, что нужно для разработки ИС - определить этапность. Что делаем и что запускаем в первую очередь, что - во вторую и т.д. Это очень важно - так как позволяет четко очертить пожелания Заказчика к тому, что должно работать в первую очередь, а что должно быть запущено в последнюю очередь. Кстати, если есть сроки - то им место тут же.

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

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

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

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

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

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

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

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.

Прислали. Совершенно замечательная картинка "Аналитика карандаша" (особенно рекомендуется РП и аналитикам).

Нажмите для увеличения (просмотра в полный размер).

Ну, очередной пост про "организацию" :) На сей раз - про организацию себя, любимого.

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

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

И для всего этого нужно одно - единственное: подвинуть себя. Дать легкого или не очень пинка. Встать, взять и сделать :)

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

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

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

Как-то так.