Проект - не проект 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. (как мне кажется)

Эволюция орг.структур компаний, методологий ведения проектов (действительно ли "все движется вперед"?)

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

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

"Поучайте лучше ваших паучат" ("а вот можно без "водички" и сразу к делу?")

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

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

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

Вот так много букв написал чтобы подвести собственно к вопросу - "разделяете ли вы при организаци рабочих совещаний участников вашей команды по уровням вовлеченности?"

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

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

Поэтому и выскажусь (в качестве еще одного "советчика") :) Выскажу "совет" именно как один из вариантов решения.

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

Цените свое время. Особенно если вы не любите его проводить на совещаниях.
Лучше тупо и бесцельно поиграть в какую-нибудь очередную компьютерную игрушку  или пересмотреть матч любимой команды за 20.. год, чем сидеть на совещании "очень умных людей".

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

(планирую по поводу совещаний/обсуждений написать еще немного, но чуть позже, хотя и наболело)

Профессионально курим :)

Никогда не делай то, что тебе неприятно. Ты сделаешь это плохо.
Либо измени свое отношение к тому что делаешь. Либо откажись вообще.

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

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

Не стоит трясти дерево с зелеными плодами.
Придет время - и яблоки сами упадут тебе в руки.

Но ты должен быть готов к этому.
И именно в направлении этой "готовности" ты должен делать шаги.
Остальное все - ерунда.

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

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

(Можно было поставить эпиграфом: 
"Лучше день потерять и за час долететь".)

... Ты скажи, ты скажи: Что те надо? Что надо? ...

Этот пост все о той же ситуации: есть Заказчик, есть вы - аналитик, есть запрос "мне нужна вот такая система".

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

Пример из жизни. 

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

Про причины такого "не знаю чё хочу, но чувствую, что надо" говорить можно много. Их может быть масса. И сейчас не очень готов писать про каждую из них. 

Хочу привести пару советов - как из такой ситуации выходить? Как добиться от Заказчика описания требований и при этом постараться сделать это в какие-то более-менее приемлемые сроки.

Совет первый. 

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

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

Совет второй.

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

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

Совет третий.

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

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

Совет четвертый.

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

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

Универсальных советов не существует. Но сам стараюсь держать в голове эти четыре правила каждый раз, приступая к переговорам о новом проекте.

Памятка для заказчика

При выборе разработчика обращайте внимание на:

1.       Есть ли у них «в портфеле» аналогичные разработки»? Наличие близких по функционалу проектов должно не только приятно удивить вас, но и заставить задаться вопросом: не получу ли я шаблонный вариант, который был уже разработан и продан однажды, а теперь просто тиражируется?

2.      Кто предлагается заказчиком в команде проекта?

3.      Как они ведут разработку и какую документацию предоставляют? Методика ведения проектов – один из самых главных критериев при выборе разработчика. Нет правильных ответов – ориентируйтесь на свои предпочтения.

4.      Ну и конечно – рекомендации! Без этого – никуда.

К чему должны быть готовы?

1.       В КП на разработку и внедрение вы можете обнаружить, что львиная доля расходов "ляжет" на "обследование" и "внедрение". Если бОльшая часть суммы составляет разработка - "испытайте некоторое подозрение" к прозрачности формирования цены разработчиком. Если бОльшая часть прописана на внедрение – повнимательнее расспросите о иетодах внедрения и разработки.

2. Основная задача ПМ от разработчика - подписание актов сдачи/приемки и проплата вами счетов. Основная задача аналитика от разработчика - предоставить вам красивый документ (содержание не важно). Основная задача программиста - чтобы вас вообще в природе не было и он вас никогда в жизни не видел.

3.       

Сделайте обязательно:

1. Передайте им свою “хотелку” и дайте разработчику 2 дня на работу с ней. Потребуйте задать вопросы по документу в самом тексте и выслать вам предварительно. Так вы убедитесь, что они ее хотя бы прочитали.
2. Познакомьтесь со всей командой, которая будет работать над вашим проектом. Вы должны знать их всех в лицо. Им тоже будет труднее дурачить вас, если они будут видеть вас лично.
3. Узнайте - зачем в команде которую вам представили так много аналитиков и всего один программист? Почему пришли все стажеры-аналитики и не пришли программисты, которые и будут работать над проектом - они что “такие охренеть важные и занятые”, что не могут оторваться от пива с чипсами для того чтобы посмотреть заказчику в лицо?
4. Представьте разработчику всех, кто от вашего лица может вести переговоры. Обозначьте полномочия в принятии решений для каждого из представленного вами сотрудника.
5. Договоритесь о порядке работы с документами. Их перечень. Версионность. Всегда требуйте чтобы вся команда проекта читала документы. И подписывалась.
6. Разработайте сценарии тестирования. Сделайте это сами.
7. Договоритесь о порядке тестирования. Никогда не соглашайтесь тестировать “финальную версию” без того чтобы протестировать сначала “альфа” и “бета” версии.
8. Еще на этапе утверждения ТЗ начинайте для себя составлять группу пользователей, которые будут тестировать систему. Это должны быть вменяемые сотрудники, выполняющие ключевые функции в бизнес-процессе . Не включайте в группу для тестирования только “операторов” системы.
9. Пропишите срок сопровождения процесса внедрения. Объем вносимых доработок в процессе внедрения. Используйте этот период по максимуму. Все остальные доработки будут “за деньги”.

Пришли с ТЗ к разработчику? Будьте готовы к тому что:

1. К вам будут приходить 10 разных людей от компании (одной и той же, той, где вы решили разместить свой заказ). И будут задавать одни и те же вопросы. Это муторно, но в отличии от рассказов десяти следователям о том как вас ограбили, постоянное пересказывание ваших требований может быть полезно и вам, а не только “следователям”.
2. Ваше ТЗ им совсем не интересно. Они хотят составить свое ТЗ. И это правильно. :)
3. Свое ТЗ они будут составлять за деньги. У них тоже есть аналитики и их надо кормить.
4. Все сроки, которые будут вам озвучены в первые 2 недели общения - вообще не имеют отношения к реальности.
5. Если разработчик “с опытом” - он попытается продать вам “свои готовые решения”. Если он разрабатывает “только для вас” - он впервые делает такой проект.
6. Если не прописали в договоре документацию по системе - ничего не получите. Не получите даже руководств пользователей. Обязательно детально пропишите перечень документации по системе.
7. Если не прописали порядок приемки результата - порядок/сроки тестирования - получите в пользование только бета-версию

2014. Подведение итогов. (мысли, опыт, впечатления)

Удовольствия:

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

Одним из самых ярких удовольствий, которые удалось ощутить в ушедшем году – удовольствие от проживаемого в данный момент. Ощущение что именно то, что происходит сейчас – это и есть жизнь. Не вчера, не завтра, а вот именно сейчас, вот конкретно сейчас, в это самое мгновение. Осознание и проживание этого момента.

"Про уродов и людей" (моя версия):

Каким бы уродом ты не был - всегда найдется кто-то, кто будет не против с тобой пообщаться.

Управление проектами:

Проекты бывают не только в IT и строительстве. Но бардак везде один и тот же.
Знания "в области управления проектами" не гарантируют ничего. Отсутствие знаний - не является препятствием. Бери в проект того кто хочет сделать, а не того кто знает как.
Вы можете реализовать 500 страниц важнейших требований, но не сделать значок "закрыть страницу" в виде "большого красивого белого крестика на красном кружочке". И завалите весь проект. Вывод: будь внимателен к деталям.
Люди не говорят о сексе в двух случаях: либо стесняются, либо у них секса так много, что "а чё о нем разговаривать?". Вывод: не додумывай, выявляя требования.

Про общение:

Будь благодарен. Даже когда вроде не за что.
Держись с теми, кто готов учиться. Избегай тех, кто любит поучать (если кто-то рядом произносит "я знаю как надо" - насторожись).

Про всякое:

Когда тебе по-настоящему плохо - тебе никто не поможет. Если кто-то тебе может помочь - значит все еще не так плохо.
Если хочешь многозначительно выглядеть - молчи когда все говорят и иногда многозначительно кивай головой и хмыкай. Но потом не удивляйся что тебя перестанут приглашать на обсуждения. Вывод: будь проще.
"Нет ничего нового в подлунном мире", "ходить по кругу", "каждый раз на одни и те же грабли" - вроде как похожие фразочки. Но только вроде. Вывод: Денис, узри мудрость. Узри ее уже, твою мать.

О разном:

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

За этот год многое узнал. Многое узнал из того, что, может быть, и не следовало узнавать. Но в любом случае - это было полезно.

Вопросы года:
1. Как я до сих пор еще жив несмотря на диагнозы врачей?
2. Зачем девушки часто стоят скрестив ноги?
3. Почему мне часто не хватает "совсем чуть-чуть"?

Имена года:
Юлия и Денис

Оценка года:
Ты зарабатываешь 1000 рублей, а я зарабатываю - 100. Ты успешнее меня?
Но при этом у меня любимая жена и трое замечательных детей. А ты в выходные сидишь один у телевизора и телефон звонит только по работе. Я успешнее тебя? 
Выводы: 1. не сравнивай яблоки и апельсины; 2. не оценивай.

Неудачи года:

Я не смог запустить свою компанию. Не удалось. И дело не в кризисе, не в конкурентности - просто я не смог. Я про..ал. 
Вывод: хорошо, будем пробовать дальше. Будем думать, пробовать. Потому что: а какого хрена, собственно?

Добиться нормальной ремиссии не удалось. Снова говорят о необходмости всякие штуки совершать. 
Вывод: нет никаких выводов.

Я не сумел собраться и начать публично выступать. Просто пока не решился.
Вывод: ну подготовься и выступи уже. Обгадишь все, скорее всего, но зато сделаешь. А там уж будем пилить твои неудачности.

Дауншфтинг мне не удался. Наверное все же я именно такой.
Вывод: пойми - кто ты такой вообще?

Успехи года:

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

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

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

Список успехов пока не полный. Подумаю еще и дополню. 

Впервые выступил в роли "чистого консультанта". Тоже отнесу это к успехам года.

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