Как стать автором
Обновить

Комментарии 15

Спасибо за исследование. Несколько вопросов:
1. Использовался ли на проекте таймтрекинг?

2. Какова медиана и разброс по трудоемкости (time estimate) задач на анализ? задач на разработку?

1. Вопрос учитываем ли мы где-то время для бюджетирования? да, все участники проекта учитывают время нашей трекинговой системе. Но учет времени очень укрупненный — по задачам в джира мы время не трекаем.

2. У нас нет задач на анализ или на разработку. Задача одна и та же — она проходит разные стадии просто.

Спасибо! Прям то, что искал.

Подход может показаться рискованным. Ведь у нас контракт с фиксированными требованиями и бюджетом.

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

Да, это главное опасение. Есть рациональные аргументы в пользу «формализации» работы с заказчиком, есть аргументы в пользу его более тесного вовлечения.
Я думаю, некоторые вопросы сложно рационально объяснить и иногда надо сделать прыжок веры. Мне нравится тут подход Джефа Безоса, который говорит, что если вы не знаете что делать, то выбирайте вариант, который больше подходит клиенту.

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

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

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

Если не иметь крепких родственных связей, или 50% отката в госконторы лучше не соваться, и на будущее всем заинтересованным работайте через фирму прокладку с государством, так безопаснее!

Впрочем как и везде.

Спасибо за статью! Можно чуть подробней как устроена работа тестировщиков? Тестируют только готовый функционал или принимают участие в постановке требований, как проверяют, медианное время на задачу
У нас есть несколько профессиональных QA, которые уже тестируют задачи когда разработчик перекинул в Ready for Test. Аналитики сами тоже тестируют.

У нас нет задач на тестирование, задача просто проходит все этапы начиная с в анализе и тд то этапа «в тестировании». Статистика по тому сколько времени задачи находится в тестировании в принципе есть, но мы на ней не фокусируемся, тк считаем, что более правильно смотреть на общее время производства задачи, а не на отдельные этапы.

Плюс у нас делается смоук/мини регресс каждый день перед выпуском тоже специалистом QA.

QA непосредственно постановку задачи не вырабатывают, но у нас принято обсуждать «эпики» всей командой (аналитик рассказывает коротко в чем суть, пробегает по макетам экранов и тд) — там QA тоже участвуют.
Думаете, чтобы разработать ракету нужен детальный техпроект, план и далее сборка по чертежам? Тогда вы сильно удивитесь, если прочитаете, как это делается в SpaceX


Не надо вводить в заблуждение и ссылаться на то что раз SpaceX якобы делает ракеты по наитию то и все так должны делать.

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

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

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

Мне кажется должно было быть понятно, что я хотел сказать… но, возможно, стоило вообще прямым текстом эту мысль написать, чтобы было еще понятнее…

>> Во вторых…
Полностью с вами согласен )). Даже не знаю к чему вы это пишите…

Егор, спасибо за статью ​

Подскажите, а почему вы ориентируетесь именно на медианные показатели, а не, скажем, 80-ю или 85-ю процентиль? У вас такой SLA с заказчиком?

Нет, у нас с заказчиком нет SLA. Про медиану - так для статьи написал. На графиках можно увидеть другие процентили

На самом деле я больше смотрю на тренды, а не на медианы или процентили.

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

Мы не отказывались от оценки скоупа и планирования, мы просто избавили разработчиков от этого :-)

в статье коротко я написал о том как мы планируем и вычисляем сроки:

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

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