Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Такие точки легко наблюдаемы:
в том, как принимаются решения и кто имеет право их принимать;в том, как идея превращается в формализованную задачу;в том, где процесс допускает движение дальше без проверки смысла;в том, кто несёт ответственность за переход между этапами, а не за выполнение отдельных действий;в том, что считается завершённым, а что — «почти готовым».
Хочется добавить в том, как принимается результат и как дается обратная связь по полученному результату
Пьяный мужик что-то ищет под фонарем. Тут к нему под ходит милиционер и
спрашивает: "Что вы тут делаете?" Мужик отвечает: "Ключи от квартиры
ищу". "А где потерял?". "В парке". "А зачем здесь ищешь?".
"А здесь светлее ".
Контроль по абстрактным параметрам и ненужным шагам потому что "там светлее".
А value driven business / auftragstaktik это слооожнооо
Из личного опыта, основные проблемы почему срывались сроки проектов:
Шлюз согласования - все задачи проходят через согласование Product Owner, который физически не успевает вовремя все читать, разбираться анализировать так как он один и помимо этой работы у него есть еще своя и кучу совещаний на большинстве из которых он просто гость потому что так надо.
Многократная переприоритезация - каждая задача проходит несколько стадий приоритезации - при попадании в очередь аналитики, при попадании в очередь разработки, при попадании в очередь релиза. Если РП уже один раз доказал что эта задача имеет приоритет "Критичный", то зачем ему еще как минимум дважды делать то же самое?
Размазанность приоритетов - ИМХО, для выстраивания очереди достаточно трех приоритетов - низкий, средний, высокий. Все остальное - "Критичный", "Блокер" и т.п. это от лукавого. Только тратиться время на выбор правильного значения.
Неправильная оценка - постоянно, вот прямо почти каждая задача с которой мне приходилось работать была изначально неправильно оценена. Стоит например оценка 8 ч\ч, что подразумевает что в течении одного рабочего дня ты с этим разберешься, а в итоге когда задача реализована и закрыта в задачу может быть списано до нескольких недель реально потраченного времени, которое уделялось этой задаче на протяжении полугода или более. А все потому что требования были кривые или сам клиент не до конца понимал что ему и зачем нужно, либо требования несколько раз менялись из-за внешних факторов.
К сожалению все описанные проблемы являются системными в РФ :-( разработка это только частный случай причём из опыта далеко не худший. Т.к. были истинные разработчики которые строили свои компании.
Про системные проблемы посмотрите что делает Роскомзапрет, зато надёжные люди им управляют...
Если управляемость системы определяется переходами между состояниями, то эти переходы не могут быть произвольными. Для них должны существовать правила, ограничивающие допустимые переходы и делающие их проверяемыми.
До тех пор, пока жизненный цикл продукта не зафиксирован как модель состояний и переходов, любые роли, инструменты и методологии работают вхолостую.
А где и как это должно прописываться? Допустим, есть и workflow и регламент, но все же: "постоянные переделки, хаос в требованиях, конфликты между ролями и ощущение, что команда всё время занята". Что или с кем здесь не так?
Ужас, какой же я старый, как мне всё это знакомо, как оно бесило меня раньше. Теперь это осталось далеко в прошлом и, как будто, это меня уже не парит и не воспринимается как проблема. Далее пример тех бед, с которыми я сталкиваюсь сейчас. Допустим.
Проект по 44-ФЗ на 12 месяцев. Замещаем ИС, но с очень большими доработками.
Я - субподряд, разрабатывающий документацию (30+ доков). Команда - полторы колеки, суть - техписы.
КК-основной подрядчик, отвечающий за реализацию. Команда - аналитики, разработчики , архитекторы, тестировщики, очень много людей, суть - основная команда разработки.
Сроки по контракту:
4 месяц - сдача проектной документации
8 месяц - сдача рабочей документации
12 месяц - приемка ИС Заказчиком.
Но есть нюанс. Нет НПА и РД. Заказчик готов работать "от обратного", когда подрядчик КК сразу приступает к созданию системы, по ходу разработки вносятся изменения в режиме (готово-замечения-изменения), мы "параллельно" пишем доки и вносим изменения в соответствии с принятыми изменениями.
Ну, то есть я не могу получить ответы от Заказчика, я жду когда изменения поступят через КК. Всё бы хорошо, но КК приступает к реализации основного объёма в 8 месяце.
Как доходит до 12, выясняется (а я говорил ещё в 4-ом , но почему-то тогда это не выяснилось) что документы не совпадают с реализацией.
Итого: виноват я и моя команда. В следующем периоде мы должны полностью разработать as is и to be и 30+ документов, при том что нас стало ещё меньше а сроки более сжатые.
В прошлую пятницу получил ответ на вопросы от Заказчика , как обычно о том что НПА и РД по изменениям нет, всё скажем на тестировании, когда будет разрабатываться система.
А вот совсем недавно наш РП приносит ещё задачи по новым документам с формулировкой "будем делать ещё вот это... Но когда , в какие сроки - секрет, но работы много".
Обожаю свою работу! Это бездна. Как бы ты глубоко не проваливался, дна не видно.
Хорошая статья, если не сказать уникальная в своей простоте и глубине понимания проблем. Автору спасибо.
Жду дальнейших публикаций на тему или около нее.
Настолько с одной стороны свежо и настолько избито множеством хороших авторов "какую проблему решаем?", что даже не смутила реклама своего продукта.
Нашел на ютубе, видео версию посмотрю попозже.
Переспал с информацией.
Можете описать текущее прохождение задачи через роли и людей.
Я Просто вспомнил близкий по смыслу поток
бизнес аналитик
системный аналитик
Архитектор
Разработчик
Тестировщик
Релиз
Это стандартное описание коня в вакууме, предположим что каждый передает дальше свою часть работы.
Ответсвенные есть, переходы понятны, но мне часто это жутко не нравиться. Поэтому хотел прочитать про ваш поток и через каких людей это все проходит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблема не в разработке, проблема в управлении: если виноватых нет, виноватый назначается