MoneyDev: Как заработать на макулатуре

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

MoneyDev

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

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

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

Я немного отвлекся от основной темы. Так что там насчет макулатуры?

Монетизация отвратительной документации

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

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

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

● ГОСТ - в случае выявления ошибки форматирования (например, несоответствие документа ГОСТ или требованиям заказчика по содержанию документов);

● ошибка - в случае выявления ошибки содержания (несоответствие описания реальному состоянию дел, противоречие в документе);

● уточнение - в случае, если заказчик просит дополнить документ новыми сведениями, которые лежат вне нашей компетенции (например, уточнить подписанта или перераспределить полномочия, или указать новые наименования серверов и т.п.);

● перефраз - если заказчик требует переформулировать абзац; при этом изменение формулировки не меняет смысл текста;

● форматирование - заказчик требует изменить структуру документа (например, перенести большую таблицу в приложение), при этом смысловое содержание документа не изменяется;

● ретро - заказчик прислал замечание к устаревшей версии документа;

● разъяснение - вариант замечания, когда рецензент сам ошибся и с нашей стороны были даны разъяснения.

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

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

Пока мы еще не вышли на уровень Docs as Code , но теперь мы оцениваем требования по изменению документации так же, как и требования по изменению ПО. В следующем квартале после этих событий стоимость доработок по расширенному сопровождению программного обеспечения для этого заказчика возросла на 30% только за счет оценки стоимости новых требований по изменению проектной документации.

AGILE-проектирование

Однажды наш заказчик в рамках расширенного сопровождения корпоративной АСУ пожелал, чтобы наша проектная команда разработала проект технического решения по взаимодействию этой автоматизированной системы с центральной системой управления доступом. А заодно разработала и проект регламента по предоставлению доступа пользователям и эксплуатационному персоналу к информационным ресурсам АСУ. Кроме того, эти документы должны были определить приведение всей автоматизированной системы в соответствие с новыми требованиями информационной безопасности. Проблема заключалась в том, что точка зрения представителей заказчика на стоимость работ по проектированию "немного" не совпадала с нашей оценкой. Представители заказчика оценивали эти работы в 5 (пять!) раз ниже той суммы, на которую мы рассчитывали. При этом они не хотели слушать никаких наших доводов и обоснований.

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

В этой обстановке пришёл в голову следующий вариант, который мы предложили заказчику: организовать эту работу по принципам Agile. Заказчику было предложено следующее.

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

Такой подход представителей заказчика полностью удовлетворил. Единственное, что их беспокоило, - это то, чтобы разработанные проекты отражали самую суть доработок системы. Без воды. Они даже обращали внимание, что оформление по ГОСТ 2.105-2019 для них на данном этапе вообще неважно. Но тезис о том, что если им не понравится результат, они могут просто не платить за выполненные работы первого спринта, развеял все сомнения.

Тем не менее, через две недели заказчик получил проекты разработанных документов, которые были оформлены в полном соответствии с ГОСТ и содержали полное описание требуемых разделов. Кроме того, каждый из представленных документов содержал около 40 примечаний с вопросами по инфраструктуре и уточнению требований.

Буквально на следующий день мы получили ответное письмо, в котором заказчик настаивал на уточнении представленных проектов документов по ряду требований и предлагал устроить совещание по согласованию заданных нами вопросов. Однако в ответ на это письмо мы напомнили о достигнутых ранее договоренностях и сообщили, что дальнейшая разработка документов возможна только после согласия заказчика оплатить как выполненные работы, так и работы следующей итерации, объем которой предлагается согласовать. После этого нам поступило еще несколько писем с требованиями уточнить представленные документы. Однако каждый раз наш ответ был одинаков. На неделю наступила мертвая пауза. А потом мне позвонил лидер проекта со стороны заказчика и сообщил, что в принципе руководство согласно оплатить первую итерацию проектирования и готово планировать следующую. Со своей стороны я попросил зафиксировать это решение в почте, после чего мы готовы продолжать сотрудничество в этом направлении. В ходе разговора, как бы между делом, он уточнил: "А по Вашему мнению, на сколько процентов готовы эти проектные документы?" На что я ответил, что если со стороны заказчика не собираются уточнять заданные нами вопросы, то в этом случае подготовленные нами проекты документов готовы на 100%.

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

Комплексный подход

Если ничего не получается, может все-таки стоит прочитать инструкцию?

Народная мудрость

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

На одном из проектов, куда меня пригласили в качестве РП, проектная команда изо всех сил старалась показать представителям заказчика, что она разрабатывает программное обеспечение c минимальным количеством ошибок и всегда идет навстречу пожеланиям клиента. Для снижения количества инцидентов многие выявленные со стороны заказчика ошибки ПО исправлялись без лишних формальностей, по звонку от клиента и вставлялись в очередной релиз без документального оформления. Зачастую случалось, что один пользователь просил переделать алгоритм, а уже на следующий день другой пользователь требовал привести тот же алгоритм к предыдущему виду.

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

Во-первых, правила обработки инцидентов были сформулированы и задокументированы в Confluence.

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

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

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

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

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

Нововведения на начальных этапах вызвали резкий прирост инцидентов всех типов. Пошли разговоры о некомпетентности нового РП...

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

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

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

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

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

Если вы не решите эту проблему классификации инцидентов, попытки применить любую методологию управления программными проектами на проекте вам не помогут.

Магия нарисованных слов

С годами начинаешь понимать, что главное - не длина волшебной палочки, а мастерство волшебника.

Народная мудрость

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

Предки жителей Новой Зеландии были уверены, что умение надолго запомнить знание гораздо могущественнее разящих сил грома и молнии. Эта древняя магия в наше время стала еще сильнее. Но многие РП пренебрегают этой магией, предпочитая для достижения своих целей более, как им кажется, современные технологии. За деревьями иногда не видно леса. За текущими задачами РП часто не понимает, что его основная задача – обеспечить достижение целей системы, которая живет и развивается по своим законам. Зачастую эти законы формулируются в проектной документации. И от того, как вы сформируете эти законы, будет зависеть то, в какой реальности вы будете жить на проекте.

Однажды, когда я рассказал первую историю одному знакомому РП, он в ответ задал вопрос: "А они прямо с одной встречи приняли доказательства и сказали "Да, ОК. За все заплатим?" Ну прямо вопрос из серии: "И что она после первого свидания согласилась выйти замуж?" А я и не говорил, что встреча была одна. Для всех надо найти аргументы и подходы. Чтобы это было win-win. И сформировать свою репутацию. А это задача не одного дня.

Однако для этого нужно всегда помнить о цели предпринимаемых телодвижений. А главная цель была даже не в том чтобы "пробить" деньги. Это получилось случайно. Я сам не ожидал, что так можно будет. Главная цель была в том, чтобы обеспечить защиту проектной команды от "наездов" начальства как со стороны заказчика, так и со стороны своих топов, и объективно обосновать наши трудозатраты. И предвосхитить крики "Почему так долго!", "Чем вы там занимаетесь!", "Почему такое отвратительное качество!" и т.п. Другими словами - предотвратить переработки в нерабочее время.

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

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

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

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

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

«Стороны признают юридическую силу документов, уведомлений, писем и иных сообщений, направленных посредством электронной почты по адресам, указанным в разделе «Адреса и реквизиты Сторон» настоящего Договора (либо по иным адресам, письменно сообщённым Стороной). Электронная переписка между Сторонами по указанным адресам электронной почты признаётся Сторонами надлежащим и допустимым доказательством в случае возникновения споров по настоящему Договору, в том числе при рассмотрении дел в суде. Адрес электронной почты лица, с которого направлено сообщение, признаётся простой электронной подписью, а электронный документ, подписанный простой электронной подписью, признаётся равнозначным документу на бумажном носителе, подписанному собственноручной подписью (п. 2 ст. 6 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи»). Риск последствий направления и получения сообщений по электронной почте несёт соответствующая Сторона».

Только не забудьте вставить адреса электронной почты в раздел «Адреса и реквизиты Сторон».

Кстати, если ваш потенциальный партнер категорически отказывается включать такой абзац в договор, этот факт должен вас сильно насторожить. Увы, зачастую собственные топ-менеджеры не хотят вставлять эту фразу в договоры, чтобы, не дай Бог, не расстроить клиента. Фактически тем самым "стреляя в спину" своим сотрудникам, которые так или иначе взаимодействуют с представителями заказчика. Поэтому, если вас допустили к обсуждению контракта, обязательно стоит подать предложение руководству о включении этой фразы в договор. Даже если эта фраза заведомо не будет добавлена. Ну и предупредите свое начальство о высокой вероятности выплаты всех штрафных санкций по такому договору в полном объеме. Конечно, ваши предложения должны быть направлены вашему руководству в письменном виде, по электронной почте. Это письмо может вам сильно пригодиться тогда, когда будут искать виноватого за выплату неустойки.

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

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

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

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

Хакагурэ. 1716 год

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

Важно понимать, что очень часто главное не текст ответа вашего оппонента, а интерпретация этого ответа. Как вариант, если вы услышали на совещании от Заказчика или БигБосса фразу <Я вас услышал> не надо обижаться и ворчать . Просто зафиксируйте в протоколе совещания что-то вроде: "РП проинформировал Заказчика/БигБосса о возможных последствиях принятых решений и предложил возможные пути обхода рисков". А в колонке Сроки/Ответственный этого протокола зафиксировать напротив этой активности что-то вроде: "Предложения РП приняты к рассмотрению Заказчиком/БигБосом. Принято решение до особых указаний от Заказчика/БигБосса курс корабля на скалы не менять." Как правило, при согласовании проекта такого протокола Заказчик/БигБосс “немножко” поправит свой ответ.

И вот после всей этой утомительной и монотонной работы клиент начинает привыкать к мысли, что деньги придется отдать. А ведь клиент привык к другому, привык массово, безалаберно, с восторгом.

Г.А. Радзиевский

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

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

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

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

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

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

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

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