Участник:ArmorAdmin/Руководство проектами — различия между версиями

Текущая версия на 12:08, 6 августа 2020

Автор(ы): Чобиток Василий

G+

Закон сопромата: нельзя опереться на то, что не оказывает сопротивления! (народная мудрость)

Жизненный цикл ПО

22.02.2011

Как-то нанимал на работу тестировщицу, потом она стала аналитиком. Проект только начинался. Сейчас пишет:

Помнишь как ты меня на работу заманивал? «Увидишь полный цикл процесса разработки». «РТИ» уже умер — я уже все увидела.

«У меня не было времени!»

02.03.2010

Консультировал недавно одну команду по предметной области, в которой имею глубокие познания и опыт. Условно назовём эту предметную область «резинотехнические изделия» (РТИ).

Захожу. Новый аналитик (парень толковый, но ему не повезло попасть в команду не в самый простой период) радостно сообщает, что почти закончил писать ТЗ на новую подсистему системы учёта РТИ и показывает документ объёмом порядка 60 стр.

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

— Я не буду это ТЗ читать, а сразу скажу, что это хрень, которую надо полностью переделать.

— Но почему?! Как я могу переделать, если не получу от тебя замечаний?

— Хорошо. Смотри. С предметной областью РТИ ты раньше сталкивался?

— Нет.

— Кодекс про РТИ изучал?

— Нет.

— А Закон про порядок раздачи РТИ группам риска в угрожаемый период?

— Нет.

— Почему?!

— Эээээ…

— Молчи! Давай я за тебя отвечу.

— Давай.

— У тебя не было времени!

— Нуууу…. ну, честно говоря, да! Но ведь мне же поставили жесткие сроки — написать ТЗ за неделю!

— У тебя не было времени подумать, поэтому ты как офицер из известного анекдота труси́л дерево и без знаний в предметной области натрусил 60 страниц бесполезного текста. А если бы для экономии времени тебя заставили бы прыгать с третьего этажа, потому что лифт медленно спускается? Представь себе, тебе ставят задачу описать предметную область программистам и ты, не разобравшись в предметной области, строчишь по шаблону совершенно бесполезный документ на 60 страниц.

— Ну почему же совершенно бесполезный? Я общался с руководителем отдела, он мне рассказывал о предметной области…

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

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

Мой опыт говорит о следующем. Чем более сжатые сроки, тем больше времени следует уделить тому, чтобы полностью и спокойно вникнуть в проблему и тому, чтобы подумать.

Аналитик, сразу наваявший по заданию руководства ТЗ на 60 страниц, формально задачу выполнил вовремя. Но фактически он впустую потерял неделю, так как не разобрался в предметной области. Более того, руководство со своими сжатыми сроками получило совершенно непригодный к использованию документ, пойдет с ним к заказчику и начнётся многомесячный геморрой по внесению правок, взаимным упрёкам в некомпетентности и глупости, обидам и т. п. В результате реальные потери времени составят человеко-месяцы!

Что делать в такой ситуации? Работать правильно! Любая работа должна начинаться с мыслительного процесса головой и погружения в предметную область. На это в любом случае необходимо время независимо от искусственно установленных сроков. Если сроки слишком жёсткие, то лучше сразу сделать правильное ТЗ и не уложиться в сроки на одну-две-три недели. Но это будет осмысленный документ и «лишнее» время, затраченное на его обдумывание, в дальнейшем сэкономит месяцы!

P.S. Из моего в прошлом конструкторского опыта: по нормам на один лист ТЗ необходимо около восьми нормо-часов.

«Путь камикадзе»

11.02.2010

Лежу, болею, снова перечитываю эту классическую книгу. В чём-то с автором даже не согласен.

Тут приходит от знакомого сообщение:

«просто рюхнуться можно наблюдая, как по совершенно правильному алгоритму, под непрерывным контролем и наблюдением, постоянным согласованием и координацией любое дело превращается в фантасмагорию — и ты даже не можешь понять, как же это получается — вроде все правы и делают свое дело, а в результате — …»

А всё почему? А всё потому, цитирую товарища Йордона:

«Вместо того, чтобы следовать рекомендуемой кем-либо практике — или, что ещё хуже, практике, навязываемой сверху руководством и комитетами по методологии, которые обычно сами не знают то, о чем они говорят — гораздо лучше следовать практике, которую сама команда считает „наилучшей“ в данных обстоятельствах.»

Особенно, если «руководство» и «комитеты по методологии» — гуманитарии, которые на самом деле ни черта не смыслят в разработке ПО.

И ещё оттуда же:

«Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации…»

«…попытка внедрить в безнадёжном проекте новый, незнакомый процесс может закончиться катастрофически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды.»

Впрочем, не завидую я моему знакомому, его кураторам ни моё скромное, ни мнение классиков не интересно :-(

Маразматическое планирование

08.02.2010

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

Смотрит товарищ на это и грустно говорит:

— Вася, я на этом рынке больше 10 лет, но подобную х...ню вижу впервые. Что с этим делать?

— Не парь себе мозги. Хочешь я тебе расскажу, как этот план наваять за 5 минут?

— Валяй.

— Ставь проценты от 3.14-ы. Лишь бы только общие суммы были по 100 %. Но! Сделай главное: проценты должны быть с десятыми, ну там 13,5 % или 30,3 %.

— ?!

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

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

400 человеко-часов за один день

22.01.2010

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

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

Обдумав задачу, этот руководитель проекта сообщил заказчику: трудоёмкость 400 чел./час.

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

Из-за подобных «идиотов» заказчиков такие разработчики теряют свой хлеб с маслом…

Собеседование

20.01.2010

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

Хочу акцентироваться на одном аспекте.

Как-то проходил собеседование на должность аналитика. Собеседование проводил Андрей Л. Андрей гонял меня 2.5 часа. Как позже выяснилось, обычно это намного меньше, но эта беседа была для него интересна.

По результатам собеседования понял: «Если в этой компании работают Такие Специалисты, я хочу работать в этой компании!»

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

И мне перед такими людьми потом часто стыдно — впечатление от собеседования создаёт у них ложное впечатление о компании.

Нереальные задачи

20.01.2010

Многие руководители считают, что поставить жёсткие (читай — невыполнимые) рамки выполнения задачи, это мотивировать подчинённых на максимальную отдачу, потому что они будут из кожи вон лезть, чтобы вписаться в эти рамки.

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

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

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

Во вторник звонит директор:

— Когда будет полиграфия?

— Через одну-две недели.

— Чтобы была готова к этому четвергу! — высказал он тоном не терпящим возражения.

— Хорошо.

Я не стал спорить потому, что спорить с глупостью тоже глупость. И не бросился выполнять это распоряжение потому, что оно нереальное — всё, что зависело от меня уже сделано, а кипишем и изображением бурной деятельности запущенную машину никак уже не ускорить. Моя «бурная деятельность» будет только отвлекать людей, которые делают эту работу.

Полиграфия поступила в следующий вторник. Ровно тогда, когда она реально и могла поступить.

Муха и слон. Управленческая басня в прозе

13.01.2010

Сидит на куче свежего навоза стая мух.

— Нам всю кучу не одолеть! — говорит одна из них.

— Да, это не корова, а какой-то слон. — отвечает вторая.

— Я знаю, что нужно делать. В новом офисном здании по соседству такие умные люди поселились, так они вчера что-то про слонов говорили…

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

Офис 1 этажа

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

Шеф: Товарищи! В прошлом месяце наш оборот составил 5 миллиардов, прибыль — 500 млн. Аналитик Соображалкин в курилке высказал мне мыслю как сократить наши накладные расходы на 1 миллиард, в результате прибыль составит 1.5 миллиарда в месяц. Хочу, чтобы вы выслушали его соображения. Слово предоставляется товарищу Соображалкину.

Зам по науке: Извините, а можно вопрос: тов. Соображалкин свою мыслю оформил документально?

Шеф: Нет, он, к сожалению, буквы путает.

Зам по науке: Не проблема, у меня есть Писарчук, он прекрасно конспектирует и оформляет идеи.

Шеф просит секретаря срочно вызвать Писарчука. В это время влетает муха. Зам по науке, заполняя паузу, рассказывает различные истории.

Зам по науке: …да, так вот, вчера наш заокеанский друг учил как управлять проектами и загадал такую загадку: «как съесть слона?», ответ: «по кусочку»…

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

Короткая пауза. Шеф, торжествующе: «Попал!» Присутствующие улыбаются.

Зам по науке: Браво!

Шеф: извините, что прервал. Соображалкин, продолжайте.

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

Про муху все как-то и забыли.

Офис 2 этажа

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

Босс: У нас ЧП! Надо покрасить стены туалета, а Студент посыльный купил банку краски за 100, вы представляете?! За СТО!!!

Все недоуменно пожимают плечами.

Босс: Как, вы не понимаете?! На другом конце города эта банка стоит 85, передаю по буквам: восемьдесят пять!!!

Студент посыльный: я отдам, из зарпла…

Босс: Замолчите! Как вы не понимаете?! Дело не в пятнадцати! Мне не нужны деньги из вашей зарплаты! — достаёт толстый кошелек, из него купюру 20 и суёт её ошарашенному студенту, — Вот, возьмите, покушаете мороженное… Дело не в деньгах, дело в другом!!! Вы не хотите думать! Вы не хотите работать! Цели компании, трудовая дисциплина, корпоративные ценности!..

Босс, продолжает: Зам по поставкам, почему Студент не знает где и по какой цене покупать краску? Он не виноват, это вы упустили! Пишите объяснительную. Зам по общим вопросам, почему Студент не смог доложить мне цели компании? А ведь в пункте 3.18 целей компании написано: «Экономия любой ценой!» Он не виноват, это вы упустили! Пишите объяснительную. Инженер по безопасности труда, почему студент не смог доложить мне меры безопасности при покупке кра…

В это время влетает муха.

Босс: Аааа! Начальник хозяйственного отдела! Почему в офисе мухи??? Тут гов… мёдом помазано? Ага, значит ваши уборщицы плохо убирают, а вы за этим не следите!

Начхоз: Да она ж сама вле…

Босс: Молчите! Мне не нужны ваши оправдания, я хочу знать почему? Почему всё так хреново? О! Да это не муха, смотрите, какая жирная, это целый слон! Кто может сказать, что нам делать со слонами?! Специалист Прямой, доложите, что делать со слоном?

Специалист Прямой: Никакой это на фиг не слон, обычная муха, надо просто взять мухобойку и…

Босс: Никто не хочет думать! Что значит взять мухобойку? Его про слона спрашивают! Начальник отдела кадров, готовьте приказ на увольнение Прямого с завтрашнего дня, нам тут не нужны люди, которые не хотят думать. Специалист Гибкий, доложите ваши соображения!

Специалист Гибкий: Ну, я бы при борьбе со слоном предложил абстрагироваться от сущности слона и инкапсулировать её в насекомом, например, мухе. Таким образом мы можем свести борьбу со слоном к одному удару мухобойкой…

Босс: Уже лучше… Специалист Пластичный!

Специалист Пластичный, подслушав беседу снизу: Ну как же так можно? Босс сказал слон, а вы инкапсулировать его до мухи? Посмотрите на неё, это же не муха, даже не слон, а целый мамонт! Вот иностранные специалисты считают, что съесть слона можно по кусочкам…

Муха поднялась со стола и вылетела в форточку, но она уже никому не интересна.

Босс: Вот! Видите, как надо думать! Слона можно съесть по кусочкам! В самом деле, попробуйте проглотить его целиком — не выйдет! Начальник отдела кадров, Гибкого тоже уволить! Начальник планового отдела, составьте план проекта «Слон по кусочкам», вы еще не забыли, как строят диаграммы Ганта? Начфин, подготовьте смету проекта. Всем начальникам служб: подготовить служебные записки со списком мероприятий, которые необходимо запланировать службам в рамках проекта «Слон по кусочкам», записки подать до 13:26 завтра!

В это же время у кучи навоза

— Люди говорят, что навоз слона надо кушать постепенно.

— Какие светлые головы!

Мораль

Мораль сей басни такова: не делай для мухи слона.

Не мешать людям работать

12.01.2010

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

Он говорил: «Главная задача руководителя — не мешать людям работать!»

Рабочее время

29.07.2009

Вчера меня «попросили» подождать для посовещаться. Начали около 20:00, домой заявился после 22-х. Моя мама — старый больной человек. Она в этот вечер получила черствый хлеб и не дождалась мороженное, о котором меня попросила (уж негде было купить)…

Человек, который работает эффективно, успевает сделать свою работу в рабочее время. Бывают редкие случаи (где-то раз в квартал-год), когда необходимо неожиданно выполнить срочную работу, здесь надо быть готовым закрыть вопрос не считаясь со временем суток. Но по-хорошему эти случаи носят внешний характер («Шеф, все пропало! Гипс снимают, клиент уезжает!»), а не внутреннего происхождения. Если решение текущих производственных вопросов назначается руководством на внеурочное время, значит таким образом руководство поощряет подчиненных работать неэффективно.

Управление задачами

29.07.2009

Такой случай из практики. Есть руководство пользователя в PDF формате. При копировании из него текста в другой документ, буквы в заголовках повторяются по ддвваа ррааззаа, хотя в PDF заголовки выглядят нормально. Регистрируем ошибку. Вполне естественно, что на функционирование она не влияет, не критична, её можно отложить далеко на потом.

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

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

Риски

12.03.2009

Управление рисками должно быть. Предсказанная проблема — первый шаг к её избежанию.

Если проблема маловероятна и устранима за полдня в случае наступления, вообще не стоит заранее на неё заморачиваться.

Не подменяй управление рисками прикрывательством собственной жопы.

Планирование

12.03.2009

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

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

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

Раз человечество выработало механизм постепенного углубления в проблему «от общего к частному», то стоит ли изменять ему при планировании программных проектов?

В КТЦ, где я имел честь служить пять лет, учили создавать перспективный план части (на пять лет), годовой план части, годовой план отдела, план на тему^[1] в целом, квартальный план темы, месячный план и вплоть до недельного плана отдела.

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

Так может быть такое планирование не было точным? Оно было точным и по результатам выполнения темы отклонение в часах на 10 % от первоначального плана уже считалось большим. Да, бывали и переносы на другой период, если заказчик не смог вовремя предоставить исходные материалы, бывали увеличения плановых показателей, если по ходу выяснялось, что заказчику требуется больше, чем изначально планировалось. Но на каждые десять тем таких было не больше одной-двух. То есть методы планирования, которые использовали наши отцы и деды, работают! Планировать надо от общего к частному, но не в иную сторону!

Зачем я так подробно остановился на том, как было в КТЦ? Уже не раз сталкивался с идиотским посылом среди манагеров новой формации, что «пока мы не распишем все задачи (вплоть до каждого моллюска), план на проект выдать не можем».

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

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

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

Примечания

1. ↑ Тема — то же, что в программной индустрии принято называть проектом.