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

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

проекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проекты, большие и маленькие

Просмотров: 1745Комментарии: 0
IT Blogs

Давно я не писал ничего на ITBlogs. Исправляюсь....

Итак, из разряда "мысли вслух".

Обнаружил (умозрительно) парадокс. Заключается он в том, что чем меньше проект, тем более тщательное и конкретное ТЗ на него должно быть написано.

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

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

Если же вспомнить, что обычно (в правильных случаях - больших проектов) за ТЗ идет ТП, где описывается - КАК сделать все то, что описано в ТЗ, то вроде как возникает еще один повод расслабиться и вздохнуть с облегчением: уж в ТП-то будет описано все, до пресловутого "последнего винтика". Как бы ни так! В самом лучшем случае там будет описано процентов 70 того, КАК надо сделать описанное в ТЗ. 30% - на риски. Суровая правда жизни :)

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

Вот как-то так мыслится :)

Кросспост из моего ИТшного блога на ITBlogs.ru

Про видение “заказчик/продавец/исполнитель/пользователь”

Просмотров: 1367Комментарии: 0
IT Blogs

Тема стара как мир. И не о кризисе. Местами очень даже теоретическая.

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

  1. внутренняя формализация задачи - про этот этап вообще-то частенько забывают...
  2. определение, "делаем сами" или "покупаем нечто". (Предположим, что "покупаем" - так видится интереснее)
  3. мониторинг рынка и определение бюджета
  4. формирование внятного документа - приглашения на тендер (в нем, по хорошему, должны быть описаны основные моменты: зачем, что, ожидаемый результат и т.д.)
  5. рассмотрение предложений (поступают от продавца исполнителя)
  6. выбор
  7. договор
  8. внедрение (исполнитель)
  9. эксплуатация (пользователь)

П. 7 - 9 пока оставим вне рассмотрения, и перейдем к п.6 - "Рассмотрение предложений" и "Выбор". Проблема в том, что очень часто (статистика взята по 5..10 моим ИТ знакомым из разных сфер основного бизнеса) декларируемые возможности не соответствуют действительности, или соответствуют в некоторых специфических условиях. Решается все, как правило, административными мерами, доработками или патчем, что либо увеличивает бюджет внедрения, либо сроки, либо трудозатраты на баголовство.

Способов борьбы с этим явлением придумано на данный момент два:

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

Как вариант, может "прокатить" комбинация этих двух способов.

Разумеется, продавец прктически любой системы постараться избегнуть подобных опытов "по живому": трудозатраты, да и не факт, что купят. С другой стороны,- продавать надо, поэтому на подобные вещи хоть неохотно, но идут. (Встречал ОДНУ компанию, которая САМА предложила реализовать процесс в системе. Нонсенс - но приятно видеть нормальный профессиональный подход).

А теперь, внимание. Вопрос к коллегам: а как вы решаете подобного рода коллизии? Интересно мнение как "исполнителей", так и "заказчиков".

PS. Очень надеюсь на ответ А.Тенцера, М.Елашкина, А.Куприянова, В.Брокуса, П.Попова и всех-всех-всех (да простят меня не упомянутые лично). :D

Кросспост из моего ИТшного блога на ITBlogs.ru