Подсмотрел у Бигдана, вот тут: http://ibigdan.com/2012/03/15/kratkaya-pamyatka-o-srokax-proektirovaniya/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читал дочке сказку о репке. Сказка, она на то и сказка, чтобы иметь хороший и добрый конец: репку вытащили, всё гут - все довольны. А я подумал: а что если рассмотреть сказку в контексте проекта?

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

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

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

"Позвал дедка бабку". О! На проект перед самым его завершением начали подтягивать дополнительные ресурсы.

"Пришла бабка. Тянут-потянут репку, вытянуть не могут". Одно из двух: либо недостаточна квалификация ресурса, либо проект производится впервые, и никто не знает, что делать, либо дедка круто ошибся с планированием.

"Позвала бабка внучку". Началось делегирование, размывание ответственности и привлечение дополнительных ресурсов. Скорее всего - в ущерб другим проектом. (Предприятие-то малое!)

"Тянут-потянут - вытянуть не могут". В общем, известная истина: как правило, от увеличения сотрудников на проекте эффективность увеличивается, но не пропорционально их количеству.

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

"Позвала жучка кошку. Тянут-потянут - вытянуть не могут". Повторение предыдущей картины. Куча исполнителей - каждый из которых понимает процесс, но не очень желает его нарушить - можно и затрещину от дедки схлопотать: "процесс нарушаешь!"

"Позвала кошка мышку. Тянут-потянут - и вытянули репку". Судя по всему, мышка была последним членом коллектива, не вовлечённого в рабочую группу проекта. И, в контексте сказанного выше, для меня факт того, что результат достигнут, выглядит немного странно: по моему опыту, такого рода эксперименты (увеличиваем число исполнителей без всякого анализа и приложения мозга) заканчиваются довольно печально.

Что же... Сказка ложь, да в ней намёк. Всем PMам в ней урок.

PS. Если понравилось, то могу еще чего-нибудь в этом же духе изобразить.

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

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

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

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

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

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

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

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

И практически в любом проекте объем работ, связанных с кастомизацией, превышает запланированный.

Причин этому можно назвать несколько:

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

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

Российская специфика, однако.

Оригинал и комментарии: ITBlogs.ru