Если долго чем-то занимаешься, то это накладывает отпечаток на всю деятельность.

Если работаешь с несколькими инструментами, то «уже как бы и без них» и «вот только они и есть».

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

Когда зацикливаешься на некоторых «приемах», «технологиях», «вариантах получения результатов», ... — начинаешь смотреть только «в одну сторону».

Но это «совсем не хорошо».

Выясняешь «потребности» и примерно — «куда смотреть»:

Чего-то начинаешь рисовать в схему данных. И чего-то выдаешь чтобы 

Но казалось бы - вообще-то надо смотреть было бы более верхним уровнем.

И немного упорядочить, и чтобы немного читалось.

Но с другой стороны - надо было бы как-то более подробно "разложить".

Проект - не проект 2

Проект – это что-то ограниченное во времени и предполагающее уникальный «продукт/результат» на выходе (бюджет сейчас даже в рассмотрение не берем).

И вот как-то у меня в последнее время перестали складываться в голове эти вот «определения проекта» применительно к IT.

Вот приходит РП в какую-то компанию с задачей разработать и внедрить в этой самой компании какую-то мифическую IT-систему. Перед ним «вываливаются» «хотелки», он на них смотрит, обсуждает, уточняет и - запускает проект.

«Хотелки», озвученные ему на старте проекта, в большинстве случаев представляют из себя какие-то требования/пожелания к тому как должно быть. Но этот набор требований/пожеланий, как правило относится к тому, что необходимо было сделать для того чтобы было удобно работать в «ситуации вчера». РП чего-то анализирует, подбирает какую-то команду, долго и нудно обсуждает сроки и бюджет. Составляет всякие документы типа Устава, Договора. Потом приступают уже к ТЗ. Где чего-то в виде требований/пожеланий добавляется. Проходит какое-то время и рождается вот оно – «рукопожатие: ну давай уже!».

Начинается процесс реализации (формализация требований, уточнение, согласование, чёрта в ступе, …). Выявляются еще хотелки/пожелания. Начинается реализация в виде разработки. Начинаются демо (если какой-то там agile применяем). И начинают появляться уже требования/пожелания к тому, как хорошо было в «ситуации сейчас».

А тут еще неуемные на язык аналитики разболтались, да РП «продвинутый» попался. И Заказчик уже немного начинает вставлять пожелания/хотелки на «ситуацию завтра».

Проект идет своим чередом. РП, как всегда чует неладное. Начинает всякие прелестные речи о невозможности реализовать все возникшие доп.требования в рамках данного проекта. Начинаются разговоры о приоритетах. Часть хотелок/пожеланий из «ситуации вчера» из проекта выпихивают. Часть того что из «ситуации сегодня» в проект втискивается. Иногда даже засовывают пару тройку незначительных фишечек из «ситуации завтра».

Проект потихонечку катится себе к завершению. И РП откладывает себе две стопочки – «вот эти требования мы исключаем потому что «это совсем-совсем вчера» и «вот эти требования мы можем включить в следующий этап проекта развития системы».

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

Но ведь пока все это происходило – компания развивалась. Стейкхолдеры всякие мысли понадумали. Появилось новое понимание как «должно работать» все по процессам. А значит – появились мысли о том, что можно было бы «заложить в систему» «на завтра».

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

Так вот возвращаясь к тому, что меня понемногу тревожит (заставляет задуматься) в последние несколько лет – можем ли мы точно говорить о границах проекта? Если я работаю «на стороне Заказчика», то я ведь понимаю, что с окончанием проекта как-то «обозванного» развитие системы не заканчивается. И пойдут «доработочки» (никто нигде не документирует), пойдут требования/пожелания. Жизнь идет. Но проект-то закончен.

И может быть уже начались переговоры о новом проекте. (снова «хотелки/требования» из разряда «ситуация вчера», снова ..).

Это очень похоже на то как вырастает человек. Вот вроде бы сейчас пока еще младенец и есть всякие штуки, связанные с этим состоянием (домашний манеж, учимся кушать из тарелки и не бросать кашей в собаку), а вот вдруг раз – и уже в ясли надо идти. Проект «домашнее воспитание младенца» закончился – начался проект «ребенок ходит в ясли». А потом – «детский сад закончен»/ «пошел в школу», …. И в каждом случае присутствует то самое окончание проекта («акт сдачи/приемки»). Но ведь для самого этого самого «вырастающего человека» нет никаких контрольных точек, нет ничего такого что, вдруг заставило бы «завершить этап» и на время пойти тихо-спокойно отдохнуть и «взять паузу». Жизнь не прерывается у него ни на минуту. Все время что-то происходит.

Мне кажется, что отношение к проекту в IT надо больше соотносить с воспитанием детей. А не с постройкой дома. J

Проект - не проект

Задался тут вопросом :)

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

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

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

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

А теперь, собственно, к вопросу (вопрос ведь пока так и не сформулировал).

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

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

Сейчас даже не хочу обсуждать вопрос об уникальности результата каждого проекта. Вот честно - достали с этой уникальностью. Дом построить - это уникальность? А жилой массив из одинаковых домов? А продать полный набор косметики мужчине?

У каждого - свой подход к уникальности. :)

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

Вот сказали мне, менеджеру по продажам, что я долго уже тяну с заключением договора с конкретным клиентом. А я им - "слушайте, не мешайте реализовывать проект".

Или вот приходят ко мне и говорят:"Давай. Вот есть проект. Нам нужен менеджер. Вот тебе техническая команда. Надо будет - еще технарей возьмем." А по факту - надо просто чугун с болтами продать(ну от чего-то прошлого осталось - не пропадать же).

Где - проект? А где продажа?

И ведь в каждом случае - продавать-то надо.

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

Ну это если - "проект".

А если я - менеджер по продажам. И не очень так сведущ в этой всей проектной практике. То меня ведь запросто можно просто "по-тупому развести". :) «Не выполняешь план». И все-такое.

Сложный, в общем, это вопрос – определение грани между проектом. И «не проектом». 

Устойчивость мнений

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

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

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

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

Три реальных истории о разработках продуктов

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

Итак. Начиналось все очень похоже.
Небольшую компанию программеров, захваченных какой-то технической идеей, приглашает владелец определенного бизнеса и говорит: "ребята, мне нужна система для управления компанией. сделаете?" Во всех трех случаях "ребята", конечно же, бодро ответили: "не проблема, сделаем!".
Если говорить о компаниях, владельцы которых вот так пригласили разработчиков: производственная компания, компания-дистрибьютор иностранных производителей и строительная компания. Это не принципиально, просто для того чтобы в дальнейшем было удобнее было их обозначать.

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

Потом разница в этих историях стала расти.

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

Вот такое бывает.

Просто запишу для себя.
Старый стал.
Забываю много.

Ха, да это точно. Просто "классика жанра" - 2

Как-то давно обещал продолжить выкладывать некоторые "типичные ситуации" из опыта реализации IT-проектов.
(начал здесь:  http://strangedelivery.blogspot.ru/2014/07/blog-post_25.html )

Вот еще парочка в копилку.

"Не надо мне тут рассказывать. Я из того поколения, которое воспринимало Рабыню Изауру не как объект, а как класс."

"- Вася, ну как там у нас с разделением заказа на несколько накладных?

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

   Ну тут пока еще немного общий план "съезжает", но я уже почти разобрался.

 - Вася, они просили поправить разбивку заказа на накладные. Там сумма "не бъется".

 - А, да там делов на 5 минут. А тут вот смотри - опс! И все - видно что и где заказано. Можно еще в углу добавить ...

 - ...

 - Да ладно. Сделаю я сейчас разбивку. Не переживай. Чего-то ты грустный какой-то."

"Оцени результат" (бывают ли проекты "неуспешными"?)

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

В качестве примера приведу собственный опыт (это был мой первый проект в жизни).
Я пришел в компанию региональным менеджером по продажам. Но меня через 2 недели вызвал владелец и мне было предложено заниматься "более актульным и, на их взгляд, подходящим мне" - проектом вывода на рынок нового продукта под их торговой маркой.
Не буду описывать мой тогдашний шок от такого предложения. Не буду рассказывать обо всем, что произошло в самом проекте. Главное - что получилось в результате.
А в результате проект длился 4 месяца (если я все правильно помню). И был закрыт владельцем компании.
Перед этим владелец компании вызвал меня и "предложил" отчитаться о проекте.
Я был полностью уверен, что проект провален (и был провальным изначально). Просто как совсем "молодой специалист" в области PM я этого сразу не мог определить.
При разговоре с владельцем я сначала попытался рассказать о том, что все вроде бы неплохо (мы к тому времени почти "вышли в ноль"). Но он перебил (возможно, отчасти и видя мое кислое лицо) и предложил рассказать о том, что в проекте не так. И почему.
Я довольно четко перечислил причины, по которым считаю, что не достигаем тех показателей, которые были поставлены как цель (вообще-то, это были достаточно расплывчатые критерии оценки, но все же они были).
И (вот тут просто ставлю себе памятник :) ))))) даже четко расписал свои собственные ошибки. Не все, но основные.
После чего мы говорили еще час.
И выяснилось, что этот "вывод продукта на рынок" он рассматривал как "безопасный полигон для отработки ошибок".
Он открывал новый бизнес с новыми партнерами(практически проектную компанию)и не хотел в нем прогореть. В "этом своем" бизнесе он точно знал, что покроет убытки (если таковые случатся). А вот "туда" хотел придти уже подготовленным.
Вопрос. Проект закончился неудачей (производство продукта закрыли, контракты с поставщиками сырья разорвали, перед постоянными клиентами вроде как облажались).
Но был ли проект неуспешным?

Мне кажется, что при выставлении оценки проекту (когда такую оценку выставляет именно внешний "наблюдатель/эксперт") надо быть "менее категоричным". :)

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

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

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

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