Блог Александра Башкирова

ИТ и бизнес, компьютеры и ПО, фото, программирование и просто мысли…

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

Метки: проекты

Павел Алферов: концепция контрольных точек

Рубрика: Alib.spb.ru -> Работа

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

Ссылка на интервью:

https://www.youtube.com/watch?t=130&v=BB-TUZ_iHkw

Само интервью:

Пост про то, как надо писать ТЗ

Рубрика: Работа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как я не попал на "Второй план Б" и что из этого вышло

Рубрика: Alib.spb.ru -> Работа

Нет, я не тормоз:) И лучшее тому доказательство - что я все-таки сел писать этот пост. Несмотря на то, что времени прошло почти 3 месяца. Но - обо всем по порядку.

23 февраля 2013 года славная компания Яндекс проводила мероприятие под названием "Второй план Б". Я туда подал заявку на спикерство, но - пройдя несколько итераций был забракован, как "не формат". Впрочем, что не делается - к лучшему: 23его я оказался категорически занят. А так на меня и не рассчитывали. В общем, все бы было неплохо, если бы не одно маленькое "но": я готовился, и готовился очень серьезно. Презентация, которая получилась на выходе, мне лично казалась довольно удачной ... в итоге, подумав, решил, что презентация стоит того, чтобы выложить ее тут. В конце концов, она делалась, чтобы стать достоянием общественности. Так почему нет?

В общем, вот: Второй план Б - презентация

Ну и пользуясь случаем, сформулирую несколько очень важных моментов, так или иначе следующих красной нитью через презентацию:

  • Управление проектами - это то, чем занимаются руководители проектов, а не то, что воплощают в себе методологии и программное обеспечение. (Цитата отсюда)
  • Проект - это то, что должно быть реализовано целиком. Но если сначала реализовать самое важное, то будет немного проще.
  • Не все задачи в проекте самоочевидны;
  • План всегда будет скорректирован;
  • Эффективный руководитель проектов - тот, который в срок запустил проект, не выйдя за границы бюджета;
Это, разумеется не все. Но, так сказать - основное.

BABOK: свод знаний по бизнес-анализу

Рубрика: Работа

Коллеги подкинули интереснейшую вещь. Называется BABOK (Business Analysis Body of Knowledge), представляет собой профессиональный свод знаний по бизнес-анализу.

Исходная "поодкинутая" мне ссылка: http://lib.uml2.ru/BABOK

Посмотрел переводы и ссылки - вещь! Мне однозначно понравилось :)

Хорошо очень структурирует знания по бизнес-анализу. Помню, когда читал ITIL, подпрыгивал: вот! я же это знаю! только забыл! тут было примерно то же самое, но только применительно к бизнес-анализу.

Собственно, потому и рекламирую. )))

Случайная фотография

Орфография

Система Orphus
Дизайн от: Templates Next | Адаптация d51x