Комментарии 20
У меня был случай когда заказчик (работодатель) хотел... то ли некой магии, то ли научного открытия. Мне описывали некую систему, которая должна делать то-то и то, так-то и так-то... (нечто связанное с хитрой обработкой данных). Я кивал, мы что-то рисовали - какие-то квадратики и стрелочки... Деталей уже не вспомню, и я всё ждал когда же мне объяснят суть, как работает ядро системы - функционал был весьма нетривиальным, но заказчик был из научной среды и я ждал, что у него есть некий туз в рукаве которого он сейчас выложит. . Условный пример - заказчик хотел такой аппарат, чтоб он телепортировал предметы весом до 100 кг, с габаритами до 1 метра, на расстояние до 100 км. И обсуждает с вами цвет окраски корпуса, максимальный вес, каким замком открывать и закрывать телепортационную камеру... Когда я же я спросил - так а как же, т.е. на каком принципе этот телепортатор будет работать, заказчик просиял и сказал: "Вот! Это самое главное, что вам надо придумать!"
:) Да, характерная история. Заказчик один раз обратился к нам за реализацией рейтинга, так вот методологии не было и пришлось придумывать и предлагать её заказчику... Но самое интересное возникает, когда ты (возможно, по не опытности) вписываешься в проект, предполагая, что у клиента есть ответы на такие ключевые вопросы, а их нет... А у проекта уже есть цена и срок...
Мне босс выдал задание - написать микросервис, который получает данные из одного API и пихает в другой. Спецификация протокола - меньше страницы, нагрузка никакая. Фигня, думаю я и сажусь читать детали протоколов. На выходе - инфа о машинах в подземной парковке - время прибытия, убытия, марка, номер. А на входе.... - фото с камеры наблюдения. Барабанная дробь. И всё это задолго до YOLO3.
Один знакомый считал сбя гениальным программистом и подрядился на подобную задачу - написать распознавание лиц с камеры. Время - середина 90-х. У него был некий датасет фотографий и программа работал на удивление хорошо... вроде, потом он нашел какую-то элементарную ошибку и... всё. Программа работать (т.е. распознавать) перестала навсегда.
Я не знаю, в чём тут проблема. Аджайл всё давно решил.
Здесь надо просто поменять установки в голове. По моему опыту работы с разными заказчиками:
Для заказчика нормально не иметь разумных мыслей по поводу затеваемого проекта. Для многих людей в принципе не иметь разумных мыслей выходящих за рамки повседневно исполняемой работы - естественное состояние.
Для большинства нормальных людей - не иметь абстрактного мышления или представлениий о формальной логике является совершенно естественным. Большинство этому никогда не учили, заметное меньшинство генетически не способно этому научиться даже если захочет.
Если вы спрашиваете человека о возможных улучшениях, то ответ почти всегда будет в духе идеального транспортного средства в эпоху средневековья: лошадей добавить, колеса сделать повыше, золотом погуще обмазать. Гениальных Леонардо которые в ответ на вопрос могут начать рисовать вертолет - несколько штук в целое поколение.
Очень часто заказчики воспринимают программирование как магическое явление, которое может само по себе решать любую проблему. Несть числа я спорил с руководителями предприятий, которые требовали чтобы система не давала оформлять документы на продукцию имеющую (относительно терпимые) несоответствия (например, по весу). Они были уверены что если такой запрет сделать, то производство перестанет производить лажу. Это такой способ бегства от реальности, потому что альтернатива - это замена оборудования, изменение бизнес-процессов и прочая головная боль. Всякий раз когда такая функция была реализована, она выключалась максимум через неделю - потому что поставить клиенту продукцию не вполне соответствующую характеристикам (и, например, дать скидку) гораздо лучше чем иметь через день разъяренного клиента со вставшим техпроцессом по причине отсутствия входных деталей/сырья.
Поэтому - в первую очередь зачеркните и выбросите все, что заказчик сказал вам ДЕЛАТЬ. Вместо этого, разбирайтесь в его бизнесе - и узнавайте, какую проблему он хочет РЕШИТЬ. Я неоднократно на этом этапе объяснял менеджменту и владельцам, что они на самом деле не хотят сейчас заказывать никакое ПО. А хотят, например, заняться бизнес-процессами или элементарным выяснением между собой - какой вопрос они решают и какие цели ставят.
Дальше - предложенное в конце Time&Material - это хорошая идея для ситуации когда неопределенность высока. В проекты с Fixed price (это то самое, с ТЗ) - можно идти только тогда, когда вы уже решили 2-3 аналогичные задачи в этой сфере бизнеса, и уже имеете на руках на 90% готовое решение. В этом случае у вас конский (в разы) запас на всевозможные переделки. Играть на незнакомом поле в фикс-прайс проект с запасом 30% - лучше уж в казино сходить! Хотя бы удовольствие получите...
Что же касается ТЗ - это из серии "больше бумаги - чище задница". Вам нужно понимать критерии по которым заказчик будет оценивать успех вашего проекта. Если ваш проект успешен по критериям заказчика - вам подпишут любой акт, и не важно какие пункты ТЗ выполнены или не выполнены. Потому что альтернатива - это вы прямо завтра снимаете свою систему, и бизнес возвращается в ту точку, где он жил до начала внедрения. При правильном ведении проекта - одна мысль об этом вызывает в офисе ужас и революционные настроения одновременно. Вспомните шутку еще времен FidoNet: "К теплому туалету привыкаешь за неделю, а отвыкать обратно потом приходится всю жизнь...". Это прямое указание, как надлежит вести проекты.
Чем раньше вы сможете показать клиенту что-то с чем он может взаимодействовать - тем больше полезной информации в форме критики вы сможете получить. Ну потому что ни один нормальный человек (хотя бы и я сам!) не в состоянии нарисовать колодку по которой надлежит ему шить туфли, но прекрасно может описать (и даже показать пальцем!) свои ощущения если туфли жмут. Это касается всего - начиная от эргономики щита атомной электростанции и до вкуса блюд в ресторане...
Еще есть категория заказчиков которые занимаются самолечением, а вас зовут только для того, чтобы иметь возможность на кого-то свалить (отрицательный) результат. С ними надо дружить, пить кофе, давать советы, внимательно наблюдать за результатами их опытов на себе, но ни в коем случае не заключать договор и не брать денег. Ибо они - клиенты психиатра по большому счету, а не разработчиков.
Крутой коммент. Спасибо. Можно прямо отдельный пост написать, детализировав поднятые аспекты вопросы.
Полностью поддерживаю тезис, что нужно исходить из бизнес-целей клиента в первую очередь, когда вы беретёсь за проект. Именно этот подход позволит создать ценный продукт, который нужен клиенту, а следовательно клиент закроет глаза на то, что было в договоре. Но это по-сути, лучше решать на начальном этапе выстраивания отношений с клиентом, поясняя как может развиваться проект и договариваться о том, что является ценным продуктом проекта и как он будет оцениваться.
Тезис про самолечение мне видится больше про то, что да, у клиента другие потребности и внутри нет воли/желания/бюджета реализовывать то, что нужно компании. Часто за этим стоит банальная некомпетентность.
По обратной связи - да, работа с клиентов на проекте (как его еще иногда называют аккаунтинг) - ключевая вещь, чтобы понимать, как развивается проектный процесс, чтобы не прийти к истории №1, с которой мы столкнулись 20 лет назад, когда только начинали.
По поводу моделей (T&M, Fix) очень часты случае, когда не только вопрос неопределенности проекта, а очень определено, что требования будут меняться :) Одна из мыслей именно в том, что не нужно заниматься самообманом и контрактоваться на проект, в котором точно всё поменяется, и не так уж спасительно ТЗ, на которое многие уповают. Да, можно работать по этапам, можно и по ТЗ, и по T&M, главное понимать как проект достигнет бизнес-целей Заказчика.
Ну в общем, мы примерно с одними заказчиками работали получается... :-)
Единственное я уточню по обратной связи. Большинство проектных методик (взять тот же PMBOK) предполагают что объективно существует (в головах у людей, либо даже без определенного носителя) точная картина желаемого будущего. И дальше вопрос заключается только в том, обнаружили ли мы соответствующих людей, и применили ли мы к ним правильные методики, чтобы этот образ вытащить и закрепить в виде документа. Дальше те, кто верят в исходный постулат будут бесконечно спорить о том, как правильно искать людей, какие вопросы задавать, как надо назвать разделы ТЗ, и в пределе - какие отступы от полей надо делать справа и слева.
Я - информированный пессимист, который уверен в обратном. В России (насчет EU/USA - там видимо ситуация другая, иначе они не родили бы все эти методики управления с ТЗ) конкретного образа будущего не существует. Так учит нас вся история начиная с 1991 года. Тут тебе и кризисы каждые 5-10 лет, тут тебе и неразвитость институтов, и ужимки и прыжки федерального правительства, и неквалифицированные управленцы, и модель страны центр-колония, и что угодно еще.
Поэтому мы, не поддаваясь иллюзиям, должны опираться вместо "образа желаемого будущего" на примитивный диагностический критерий: "Если пациент орет - значит ему больно!" (C) Стоматолог в СССР при пломбировке каналов. :-) Соответственно, проектная работа - это сбор информации где болит, и максимально быстрое предоставление новой итерации, чтобы снять карту - где теперь болит меньше, а где больше. Такой вот agile с оттенком садизма. Но по-другому пока не умеем, а работать надо...
Я иногда думаю, что скрам и аджайл придумали для таких заказчиков.
Совещания есть, всё что-то обсуждают, чот презентуют, ругаются, меняют на лету ТЗ, церемонии, показы херо-мое.
Заказчик в экстазе, програмисты трахают вола за большой прайс, когда деньги заканчиваются, проект выкидывается. Ищем нового заказчика.
Agile это и есть то, что у Вас фигурирует под номером 3.
Существуют и другие причины "странного" поведения заказчика:
пока не будет создана некая чудо-система (по управлению проектами, анализу рынка и пр.) не ждите от нас качественного выполнения наших должностных обязанностей и чем дольше будет длиться этот проект, тем лучше;
внедрение изменений в бизнес-процессы потребует существенной переработки ИС, теперь ответственность на ИТ, а не на бизнес-подразделении и это прекрасно;
мы разработали замечательную идею как повысить качество управления... для этого вам надо сходить в соседний департамент и убедить их. А сами? А мы с ними не разговариваем.
Вот это вот все называется "управление ожиданиями заказчика" РП должен уметь это делать, не умеет, то ему ни аджайл, ни прибитый гвоздями из пунктов ТЗ водопад не поможет.
По своему собственному опыту могу сказать, что наиболее эффективным является постепенное внедрение бизнес-процессов, которое начинается буквально с ручной работы. Если какой-либо бизнес-процесс признается перспективным или необходимым - нужно попробовать выполнять его вручную. Это может потребовать дополнительных усилий существующих сотрудников или даже временного найма новых, но при этом, наблюдая за тем, как процесс выполняется вручную, можно пробовать его автоматизировать. У такой автоматизации есть явные союзники - сотрудники, которым подкинули дополнительную работу, желающие от нее избавиться (или максимально облегчить), или руководство, не желающее далее платить дополнительно нанятым временным сотрудникам. Нужна новая печатная форма? Прекрасно, пусть специалист сначала составит её вручную, после этого будет нетрудно её запрограммировать и внедрить. Такой подход работает не всегда, но точно избавляет от отношения вроде - пока не автоматизируете все в совершенстве, мы к новому бизнес-процессу даже не приступим
Да, согласен, правильная практика. "Если автоматизировать хаус получится автоматизированный хаус". Вначале понятный процесс, потом автоматизация. Практику можно расширить, например, используя типовые инструменты для автоматизации вместо интеграции их в большую внутреннюю систему(условно, да, мы пока считаем в Excel-ке, а потом это уйдет внутрь когда будет отлажено).
Проблемы, описанные выше, не специфичны для IT, и стандарты управления проектами позволяют таких проблем избегать.
Если нет заказчиков, то приходится браться за любой проект в обход принятых в индустрии стандартов и методик. Если заказчики есть, то стоит придерживаться стандартов управления проектами.
Бизнес-аналитика ("изучение бизнеса"), составление проектной документации, оценка проекта стоят денег. Если заказчик не согласен см. 1.
Этапы приёмки (и оплаты), матрицы ответственности, change management были придуманы не просто так. Вся цепочка бизнес-требования->продуктовые требования->функциональные и нефункциональные требования с прописанными критериями приёмки существуют и работают. Да, это работа менеджера проекта под капотом. Это не нравится CEO? - Пусть мучается дальше бытийными вопросами "почему множество ИТ-проектов проваливается?". Не нравится разработчику? - Дайте хлебнуть административки, коммуникаций с клиентом, отсутствие процессов на новом проекте. Не нравится заказчику - см 1.
Случай: есть ТЗ, есть запись всех звонков на стадии обсуждения проекта и вроде как понимание заказчиком, что означает МВП и что туда будет включено. Но чем дальше в лес, тем больше фич и фраз "мы так не договаривались". Вроде понятные формулировки для обоих становятся абсолютно разными в понимании сторон.
Получается не диалог, а тыканье носом в договоренности и не теплые отношения, так как у заказчика формула ожидание-реальность пошла по классическому маршруту.
Работаем по Time and Material но времени на обсуждения и доказательства трятится больше, чем на собсна работу. Устала ппц
Господи, но если же вы на T&M - вам какая разница как заказчик хочет переформулировать задачу ? Если вы в Agile - то это не то чтобы хорошо, но нормально: по мере того как проект пошел - у заказчика начало появляться понимание, что ему реально нужно. Берете продукт-оунера с его стороны, чистите бэклог от неактуальных задач, добавляете актуальные, и погнали спринты. Если это T&M - вы зарабатываете денежку каждый спринт и каждую фичу которую сдаете. Поэтому вы готовы хоть бесконечно все это менять и бесконечно разрабатывать. Если заказчик хочет сокращения сроков - увеличиваете цену и размер команды... Вот если бы у вас был фикс-прайс, то тогда да могла бы быть трагедия.
Почему множество ИТ-проектов проваливаются?