Комментарии 15
Спасибо за исследование. Несколько вопросов:
1. Использовался ли на проекте таймтрекинг?
2. Какова медиана и разброс по трудоемкости (time estimate) задач на анализ? задач на разработку?
2. У нас нет задач на анализ или на разработку. Задача одна и та же — она проходит разные стадии просто.
Спасибо! Прям то, что искал.
Подход может показаться рискованным. Ведь у нас контракт с фиксированными требованиями и бюджетом.
Вот этот вопрос интересен. Вы ведь принимаете на себя обязательства выполнить фиксированные требования. А потом отдаете заказчику право управлять приоритетом задач и выставлять улучшения. Что будет, если на стороне заказчика примут обоснованное бизнес-решение что вместо фичи А (в юридическо-согласованном скоупе) надо сделать более проработанней фичу Б, и в результате фича А вообще не попадет в срок контракта. Итого вы подошли к концу контракта, потратили бюджет, удовлетворили фактически заказчика, но не выполнили юридические обязательства по скоупу. Что дальше?
Я думаю, некоторые вопросы сложно рационально объяснить и иногда надо сделать прыжок веры. Мне нравится тут подход Джефа Безоса, который говорит, что если вы не знаете что делать, то выбирайте вариант, который больше подходит клиенту.
Я верю, что для заказчика лучше вариант, когда мы работаем прозрачно, когда очень рано показываем свои решения и оперативно получаем обратную связь. В этом случае результат будет лучше для заказчика и его удовлетворенность от работы с нами вырастет. А если удовлетворенность вырастет, то возникнет другой уровень доверия и можно будет стараться подходить к описываемым вами ситуациям с позиции win-win.
Одна фирма в Киеве так же участвовала в разработке электронного билета ( общий подход как у вас, договор финансирования 2% от оборота по электронным билетам), в итоге имеют тёрки в попытке отжать проект.
Уверен что в некоторых случаях даже от госкомпаний можно ждать броска через бедро.
Если не иметь крепких родственных связей, или 50% отката в госконторы лучше не соваться, и на будущее всем заинтересованным работайте через фирму прокладку с государством, так безопаснее!
Впрочем как и везде.
У нас нет задач на тестирование, задача просто проходит все этапы начиная с в анализе и тд то этапа «в тестировании». Статистика по тому сколько времени задачи находится в тестировании в принципе есть, но мы на ней не фокусируемся, тк считаем, что более правильно смотреть на общее время производства задачи, а не на отдельные этапы.
Плюс у нас делается смоук/мини регресс каждый день перед выпуском тоже специалистом QA.
QA непосредственно постановку задачи не вырабатывают, но у нас принято обсуждать «эпики» всей командой (аналитик рассказывает коротко в чем суть, пробегает по макетам экранов и тд) — там QA тоже участвуют.
Думаете, чтобы разработать ракету нужен детальный техпроект, план и далее сборка по чертежам? Тогда вы сильно удивитесь, если прочитаете, как это делается в SpaceX
Не надо вводить в заблуждение и ссылаться на то что раз SpaceX якобы делает ракеты по наитию то и все так должны делать.
Во первых это не правда. Специально перечитал главу про SpaceX из книги на которую вы ссылаетесь. Нет там ничего о том что сейчас они собирают ракеты без плана и чертежей. Могу предположить что возможно на начальных этапах что-то подобное и было, когда Макс сам за это отвечал но все мы помним как его ракеты взрывались а потом он и сам признал в одном из интервью что если бы на его месте был бы более опытный человек этих взрывов можно было бы избежать но на тот момент такого человека не было.
Во вторых мне кажется что нежелание продумывать детали фичи перед началом работы над ней прикрываясь всякими там Agile характеризует руководителя проекта как человека не способного стратегически мыслить и доносить свои мысли и идеи подчиненным в понятной для них форме. Конечно не все можно продумать заранее но любые ошибки найденные на этапе планирования исправить проще и дешевле чем те же ошибки (я сейчас не имею ввиду баги разработчиков) сделанные на этапе разработки.
В третьих, я сам руковожу проектами и ставлю задачи командам, и предыдущее утверждение основано на моем личном опыте.
Мне кажется должно было быть понятно, что я хотел сказать… но, возможно, стоило вообще прямым текстом эту мысль написать, чтобы было еще понятнее…
>> Во вторых…
Полностью с вами согласен )). Даже не знаю к чему вы это пишите…
Егор, спасибо за статью
Подскажите, а почему вы ориентируетесь именно на медианные показатели, а не, скажем, 80-ю или 85-ю процентиль? У вас такой SLA с заказчиком?
Мы не отказывались от оценки скоупа и планирования, мы просто избавили разработчиков от этого :-)
в статье коротко я написал о том как мы планируем и вычисляем сроки:
Мы отказались от традиционного планирования этапов с помощью диаграмм Ганта и оценок задач с привлечением разработчиков. Теперь используем прогнозирование с помощью имеющейся статистики. Главный аналитик оценивает количество историй, которые нужно реализовать для каждого блока функциональности, техлид смотрит, нет ли особенно рискованных требований - сопоставляем имеющиеся у нас возможности с потребностями заказчика. Если видим расхождения, то обсуждаем сами задачи и ищем решение, как уменьшить объем (предпочитаемый способ). Если так не получается, то тогда думаем над тем как увеличить команду.
Совместить несовместимое: Канбан-метод + DevOps на госпроектах