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

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

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

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

Руководитель отдела продаж оптовой компании обращается с запросом: "нам нужна 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. не оценивай.

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

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

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

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

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

Успехи года:

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

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

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

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

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

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

О выступлениях/презентациях

Презентации бывают:

1.  "вживую" с сопровождением файла
2. в виде файлов
3. динамические (рисуем на доске, показываем демо)

   

Вообще – есть презентации перед аудиторией и есть файлы презентаций.

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

У вас должно быть две версии презентации – одна для показа вживую, другая – для предоставления в качестве файла. 

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

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

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

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

О выступлениях на форумах/конференциях

Не задавайте вопросов аудитории чтобы услышать ответную реакцию. Вас пришли послушать. Не надо «втягивать в диалог». Кто захочет –сам спросит. (Хотя это утверждение очень спорно, конечно. Во многом зависит от аудитории.)

 Не превращайте свое выступление в обучение. Это учительский прием – «кто из вас знает то, о чем я буду сейчас вам рассказывать», «подведите меня своими ответами к тому, что я скажу дальше».

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

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

О подготовке к выступлению

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

В общем, дело вкуса, темперамента, удобства.

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

Подоготовка материала для выступления состоит из трех основных этапов:

1. сбор информации
2. отсечение лишнего (избыточного)
3. оформления получившегося в "съедобный продукт".

Мудрости от коллег:

От Натальи Желновой (https://www.facebook.com/nzhelnova):

"Поняла одну вещь: чтобы гарантированно объяснить кому-то что-то с помощью человеческого языка, букв и цифр, нужно придерживаться четырех простых правил:
1. Излагаем одну мысль за один раз (у доклада должна быть главная тема, и она должна быть раскрыта).
2. Главная мысль транслируется дважды: в начале и в конце доклада.
3. Цифры не должны появляться более 3-х раз в течение всего доклада.
4. Букв не должно быть слишком много (не более 5 строчек на один тезис)."

Очень интересно у Стаса Фомина:
Конференции. Памятка докладчику.

Правила управления командой

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

Правила создания команды

1. Если собираешь команду, то должен четко представлять - зачем. Потому что первое что ты должен сказать каждому участнику команды - "зачем мы здесь". (Целью создания командыможет быть не только реализация конкретного проекта)
2. Ты должен сам назначить правила. Но по этим правилам должен играть и сам. Они потом могут измениться. Но правила быть должны.
3. Ты должен сам представлять команде нового участника. Только сам. Он потом скажет что-то о себе сам, но представить должен ты.

Правила управления командой

1. Помни что ты не начальник и не директор. Ты равный среди равных. Помни об этом во время обсуждений. Иначе тебя будут бояться.(Если на обсуждениях кто-то думает о том, что его "вообще-то могут уволить", то такое обсуждение не будет продуктивным.)
2. Помни что ты руководитель команды Помни об этом во время принятия решений. Тогда в тебе будут уверены. (Ты можешь быть нерешительным, сомневающимся, кусать галстук и грызть ногти.  Можешь сомневаться даже в том, что Земля вращается вокруг солнца. До того момента, пока ты не озвучил команде свое решение. После - сомнений быть не должно. Остается только признавать СВОИ ошибки.)
3. Твоя команда - это твоя "семья". Ты должен знать всё о каждом члене команды. Но никогда этого не показывать. (Знание того, что происходит в жизни участников команды поможет тебе правильно распределять задачи и нагрузку. Команда - это, конечно, не мафия. Но некоторые принципы построения мафии очень полезны.)
4. Главное в команде - чувство уверенности каждого в том, что он "среди своих". Он имеет право ошибаться, имеет право рассчитывать на помощь коллег. Но не имеет права не предложить свою помощь другим, если он может помочь. Создай такую атмосферу. Если кто-то из участников команды не вписывается в такую атмосферу - избавься от него (с ним и дальше можно будет работать, но участником команды он уже не будет).

Ты, команда и внешний мир 

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

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

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

1. "Заказчик сам не знает чего хочет". (причем этот вариант отличается от следующего по списку)
2. "Заказчик не может внятно объяснить чего хочет"
3. Заказчик: "У меня есть уже задание, так что не нужно по пустякам отрывать моих сотрудников от работы"
4. Заказчик: "Слушайте, мне ваше тз сейчас читать некогда. Но вы же все правильно поняли? Так что давайте."
5. Разработчик архитектуры в команде, глядя на ТЗ: "И что? Ты сам все это писал? Ну-ну ..."
6. Молодой программист: "Аааа! Все понятно. Хорошо, сделаем."
7. Руководитель проекта на вопрос о сроках: "Скорее всего, если подумать, то не уложимся при любом раскладе"
8. Заказчик на первом демо: "Здорово! И это тоже можно?" Заказчик через 2 месяца: "Слушайте, я же вам в самом начале говорил... Вы вообще меня не слушали что ли?"
9. Мы - команда и решения будут приниматься коллективно. Кстати, скажи чтобы этот урод из логистики мне больше не писал. Общение с заказчиком должно быть централизованным.
10. Заказчик хочет не то, что ему на самом деле нужно (спасибо Анатолию Белайчику за подсказку)
11. Команда проекта не обладает полной информацией по проекту. Где-то "недосказаны цели", где-то - принято решение, но не все участники в курсе.
12. Дежурный вопрос "РП" - "Вася, я прислал тебе задачку. Сколько времени займет?"
       Дежурный ответ "программера" - "Я не смотрел еще. Погоди, ща гляну."
В результате получаем: "Эту фигню надо дня 2 колбасить. Хотя они вообще-то сами козлы. Так что можно и за пару часов сделать. Но по уму весь этот кусок хорошо бы переделать, а-то периодически будем на такие косяки натыкаться."

(продолжение следует)

Что нам ждать друг от друга? (Заказчик проекта и Команда реализации)

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

Вообще-то, правильнее будет такое распределение ролей: "Заказчик - Руководитель проекта - Команда разработчиков".

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

Заказчику от команды реализации:

1. Не стоит ждать от исполнителей понимания своих пожеланий к продукту проекта. У исполнителя свои пожелания, свои тараканы. Он, вообще-то, зарабатывает на вас.
2. Система, которую вам передают в качестве продукта проекта, скорее всего не будет задокументирована. Половина (в лучшем случае) ваших обсуждений не будут задокументированы. И историю проекта вы все равно не восстановите.
3. Вы думаете, что именно вы управляете тем, как все происходит? Нет. Это разработчики "рулят" процессом". И они сами решают- в какую сторону повернуть. Если зазеваетесь, то получите приложение для андроида с игрушками. Вместо системы управления проектами клиента.
4. Если в ценовом предложении пишется "4 часа работы аналитика", то это означает, что руководитель проекта пару часов покурит над вашей задачей. Не ждите что в эти "4 часа аналитика" над вашей задачей будет думать какой-то там аналитик. Никаких аналитиков нет - это миф! Два литра пива руководителя проекта с программером - это и есть описанные в КП "4 часа работы аналитика".
5. Вам кажется, что вы максимально честны с разработчиком, но это не так. Вы ему постоянно что-то не договариваете. Даже сами не замечая этого.  И не будьте "максимально честны". Просто отвечайте на вопросы, которые вам задают.

Команде реализации проекта от заказчика и руководителя проекта

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

Руководителю проекта от команды разработчиков

1. Заказчик тебя обманывает! Он хочет чтобы ты ему гарантировал написание новой операционной системы за деньги, которые могут просто покрыть расходы на написание приложения для телефона. Причем предоставил ему первую версию через месяц. И тогда он подумает - стоит ли за это платить?
2. Программист тебя обманывает! Он напишет то, что ты от него хочешь не за месяц,а за неделю. Просто ему сейчас это не очень интересно.
3. Тобой всегда  все будут недовольны. Просто потому что ты "здесь, под рукой". И тобой можно быть недовольным без опасения "навлечь на самого себя гнев начальства", без вариантов быть назначенным виновным в провале, ... Ты -удобная мишень. Ты-виноват! 
4. Команда всегда будет смотреть на тебя как на "несправедливо назначенного", если ты назначен. И всегда будет смотреть на тебя как на лидера, только в одном случае - если ты действительно лидер!

Руководителю проекта от заказчика

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

(продолжение следует)