Comments 10
Начали за здравие, закончили за упокой. У вас тоже не получилось никакой серебряной пули.
"Как мы помним, наша задача - делать все, чтобы его не двигать вправо, а если и двигать, то предсказуемо, прозрачно и заранее" -- никто не знает до момента конечного выполнения задачи сколько эта задача ещё займёт. Бывают крупные задачи, которые решаются в 2-3 раза быстрее запланированного времени. А бывают казалось бы мелкие, но сроки по которым двигаются по 5 раз.
"Разработка может вестись по спринтам, потоком по канбану или по старинке, через waterfall" -- и снова натянули agile-сову на глобус жёстких сроков =)
Agile -- как методология решения нерутинных, исследовательских задач, говорит, что мы всё равно не угадаем по срокам, надо оценивать задачи по сложности. Задача простая и прозрачная -- ставим сложность 3. Сложная и непредсказуемая -- 9. Но это не значит, что мы простую сделаем в 3 раза быстрее чем сложную задачу
не соглашусь с вами про "заупокой" :)
В статье даны 7 четких точек контроля процесса любой ИТ команды. Бери и делай.
По вашему примеру с оценкой, я скажу достаточно категорично, просто потому что у меня опыт разных оценок больше 20 лет: если человек раз за разом не попадает в оценку, он джун и ему надо учиться. Это касается и разработчика, и аналитика, и менеджера. Бывают исключения, где чистая научно-исследовательская работа, но стандартная работа ИТ отдела это: допилить интеграцию, добавить раздел на сайт и тп - не ракетные технологии.
Для примера, я давал оценку на проект за 1 млн usd на год вперед и попал в нее с точностью до 0.5% - проверил спустя год, и сам удивился.
Agile вообще не является методологией, давайте будем корректны. Это общее описание гибкой разработки, которая задается только Agile Manifesto. Принципам которого, кстати, противоречит моя статья.
И это очень важно заметить: да, для небольших команд, где продакт и команда сидят вместе то, что есть в Манифесте работает отлично. Как только растет команда - придется отделять и формализовывать все, что я описал выше.
В статье даны 7 четких точек контроля процесса любой ИТ команды. Бери и делай.
Ну это как из мультика -- "Что нам стоит дом построить? -- Нарисуем будем жить!"
Можно к примеру посмотреть на пункт 6. "Это то место, где заказчик принимает работы и должен сказать ОК. " Здесь не показано как быть в ситуации, когда заказчик по тем или иным причинам не говорит "ОК". Получается так, что мы тут что-то сделали/приготовили -- а ты кушай сам, и не важно что такой результат реальному бизнесу не нужен. И тут начинаются доработки, а это время. Это время накладывается на текущие планы по другим задачам, начинается переприоритезация задач и что-то, что планировали сделать до конца года уже сделать не получается -- и бизнес опять уходит "обманутым". Просто в данном случае остается много артефактов того, что конкретно разработка в этом не виновата -- вот смотрите на задачу, план, списание времени и результат!
По вашему примеру с оценкой, я скажу достаточно категорично, просто потому что у меня опыт разных оценок больше 20 лет: если человек раз за разом не попадает в оценку, он джун и ему надо учиться.
Скажу не менее категорично. Если вы всю свою профессиональную жизнь сталкивались только с типовыми задачами, где сроки типовые (и agile из-за этого и не нужен и даже вреден), так вот если вы не видели/не брали задач исследовательского толка, то и разработкой вы не занимались, то что вы делали называется поддержка
Бывают исключения, где чистая научно-исследовательская работа, но стандартная работа ИТ отдела это: допилить интеграцию, добавить раздел на сайт и тп - не ракетные технологии
Ну собственно говоря о том и речь. Мы смотрим с разных колоколен, но называть один колокол стандартным, а другой нет -- яб не стал
Для примера, я давал оценку на проект за 1 млн usd на год вперед и попал в нее с точностью до 0.5% - проверил спустя год, и сам удивился.
У меня тут одна большая задача в днях посчитана на ближайшие 2 года, и я сам с удивлением смотрю на то, что текущий темп совпадает с моим прогнозом, но я отдаю себе отчет в:
что это безусловно мой накопленный опыт и в большой задаче можно выделить какие-то типовые моменты, сроки который прогнозируются без проблем, но с оговоркой, что ставку исполнителя не отберут, что в отпуск длительный никто не уйдёт и тд
что это может быть просто совпадение (ошибка выжившего)
что исполнители смотрят на оценки и подгоняют/тормозят свои задачи исходя из них. То есть на одной задаче могут чуть отдохнуть и побольше почитать хабра, а на другой -- делают чуть менее качественно, но зато в срок
Agile вообще не является методологией, давайте будем корректны.
Ну это один из основных споров -- споров об определениях. Но соглашусь уступить, так как дело вобщем-то не в этом
Принципам которого, кстати, противоречит моя статья.
Об том и речь. Что Вы не замечаете огромного слона, предлагая при этом подход "для работы любой ИТ команды"
Как только растет команда - придется отделять и формализовывать все, что я описал выше.
Если большой бизнес хочет знать с некоторой погрешностью сколько будет стоить большая фича (неважно в деньгах или во времени), то да, появляются сроки, agile с часами, списание времени и прочие кровавые энтерпрайз штуки. Которые часто есть самообман да и только. И дело тут в оценке погрешности, про которую ничего толком сказать невозможно, да и те кто дают такие оценки -- не всегда те, что за них отвечают через пару лет. Даже с типовыми задачами может быть лажа, у Вас Вася справлялся с задачей за месяц, но он ушел и пришёл Петя. За сколько справится Петя? И нельзя и невозможно сравнить Петю с Васей, сколько линейку грейдов не прикладывай
Мне сдается, что у мы с вами , действительно, про разное говорим. Все верно, научно исследовательскими задачами я не занимался и никогда не руководил. Да, автоматизировал процессы, да, крупные тоже автоматизировал, но вот прямо новое - новое нет. И для нового я бы сам пробовал принципы agile манифеста: попилили - поглядели. Попилили еще. И так далее.
Ну или есть большие НИОКРы, где так не получится и надо вбухивать деньги в надежде что когда-то получится.
Такого опыта нет.
Я работал много где и я вижу, что бОльшая часть рынка - это типовые Энтерпрайз задачи по оптимизации существующих процессов. И вот в этом месте мои кубики отлично будут работать. Все компании, с которыми я сталкивался, так или иначе решали вопросы по этим кубикам.
В случае, описанном вами выше, проблемах на Приемке, это отлично описывается документом ПМИ, который основан на ЧТЗ, которое заказчик согласовал. Там есть нюансы, но всегда там можно договориться, если у менеджера проектов есть воля (ну и на фазе анализа ничего глобального не проворонили).
По новому разработчику - о да, на такое заложиться вполне можно. Я уже статистически вижу риски и закладываю их в план. Это опыт. конечно.
И осечки бывают, но среднее по больнице вполне неплохо прогнозируется :)
Ошибка выжившего. Обычно ваши кубики не выстраиваются в последовательность - все кубики (разве что, кроме бюджета) меняются постоянно и непрерывно, с сингулярностями – это такое колесо сансары. «Отменена» - это лишь одно из состояний задачи, при котором в карму команды добавляется выгорания пропорционально потраченному времени.
Нет, это не ошибка, а вполне успешный опыт моей работы и консалтинга для наших заказчиков. Я достаточно много общался с Техдирами и CIO разных компаний, я понимаю их аргументы и мне есть, что ответить.
Когда я читаю про "колесо сансары"... Я всю жизнь автоматизирую процессы. Я строил процессы гораздо сложнее того, что описан выше. И у меня вопрос: почему для бизнеса мы все можем формализовать, а ИТ процесс - это неформализуемое колесо сансары, где команда выгорает?
А не проблема ли это руководителя такой команды?
Так что буду очень раз, если вы дадите пару реальных кейсов, где указанная модель не работала.
В приведенном процессе фактически отсутствует этап проектирования и согласования технического решения. Детализации и уточнения требований заказчика по моему опыту недостаточно. Пример регламента технического решения можно посмотреть здесь.
Неа, присутствует. Это кубик "Разработка". Я прочитал вашу статью. В вашем примере это будет Разработка->Аналитика:
регламент сбора требований
регламент согласования требований
регламент постановки задач на разработку
регламент оформления выходной документации
помимо этого я уверен, будет так же много требований к разработке (как правило на таких проектах несколько команд разработки), внутреннему тестированию, ну и ПМИ (причем, не одна). И
то как раз отличный пример масштабирования моих кубиков.
К примеру, для обновления интеграции вебсайта и мобильного приложения для работы с системой Мир-Пей такого подхода будет не нужно. А таких задач в ИТ отделе крупных компаний намного больше.
Моя задача была - взглянуть на процесс работы вообще любой команды "сверху". Для начала надо так, а потом опускаться ниже, включая определение сбора требований и согласования техрешений.
И прочитал вашу статью для Ланита по организации процесса разработки.
Все так, это кубик "Исполнение" (в прошлом комментарии также "исполнение", ошибся). Как я и написал в статье:
Тут должны быть правила разработки по этапам (дизайн-разработка-тестирование), включая правила постановки задачи в вашем инструменте (трекер, как правило), правила оформления кода, правила работы с репозиториями, правила списания времени, правила внутреннего тестирования
Еще раз поясню идею: для большого проекта (например, который описываете вы), этапами по моему процессу будут следующие шаги (смотрим со стороны Заказчика):
формирование требований - происходит внутри заказчика. Компания интегратор вообще этого может не знать (ну и по ФЗ не должна знать, даже если бывает иначе)
предварительная оценка - тоже самое
согласование бюджета - аналогично
планирование - исполнителя еще нет, работы выполняются внутри Заказчика
исполнение - вот тут появляется ГК, играется конкурс и появляется компания-интегратор, тот же Ланит. Который выполняет работы, сдает и передает в эксплуатацию
А если поглядеть на работу самого Ланита, как интегратора, будет так
Пресейл
поступление требования. Ланитовский продавец приходит в Проектный офис Ланита и предупреждает, что у него планируется проект. Он не должен приходить мимо ПМО к разработчикам и аналитикам - тогда будет хаос, описанный в статье.
примерная оценка необходимого бюджета на пресейл: проводится совместно с выделенным менеджером проектного офиса Ланит.
согласование оценки и выделение ресурсов на пресейл, фиксация сроков.
Реализация
Планирование - менеджер, выделенный проектным офисом делает план и подписывается под сроки и бюджет
исполнение - про это вы написали, добавить нечего
сдача заказчику
передача в эксплуатацию
Все.
Спасибо за развернутый ответ. Однако хотел отметить, что в моих статьях описаны типовые процессы не для Ланита (в который кстати входит более 30 компаний), а только для моей проектной команды. Несмотря на то, что я публикуюсь в блоге Ланита, мои подходы не являются общепринятыми и больше демонстрируют толерантность редколлегии к моему личному мнению, чем корпоративные стандарты. Что касается масштабов проекта для которых необходимо оформление технических решений, то со временем, не сразу, для себя я понял, что разработка и согласование технических решений необходимо абсолютно для всех заданий на разработку ПО. Раньше я думал что примерно 80% требований заказчика не требуют уточнения. После сбора статистики в течении 8 лет я точно знаю что 100% требований заказчика требует уточнения. Именно превентивное согласование технических решений на связанные группы требований (не путать с техническим заданием) дает хоть какие то гарантии успешного завершения проекта.
Как помирить ИТ и бизнес, сделав разработку предсказуемой? (Базовый процесс работы ИТ команды)