Comments 22
В нашей компании взаимодействие с бизнесом тоже осуществляется только через аналитикам, и сначала разработчики сдают им истории (внутреннее демо), а потом аналитики демонстрируют продукт бизнесу. Это п.3 и 4 «опасного коктейля». Наш проект обречён?
Я не упомянул в статье один важный момент, наши аналитики проводили не только бизнес-анализ, но также забрали на себя проектирование пользовательского интерфейса и предметной области.
Если ваш аналитик выполняет только бизнес-анализ, то он возможно выполняет роль Product Owner и тогда всё хорошо — это чистый Agile.
Если ваши аналитики проводят системный анализ, то если разработчики с аналитиками образуют единую команду и единое информационное пространство (все концепции в голове аналитика, также есть и в голове у разработчиков, а аналитик в свою очередь многое знает о реализации), опять же всё хорошо — это чистый Agile, аналитик внутри команды.
Если же у вас есть барьер между аналитиками и разработчиками и аналитики выполняют системный анализ, то можно попытаться устранить этот барьер, а можно и перейти полностью на классический каскадо-водопад, с детальным ТЗ, спецификациями и проч., оставив барьер на месте.
Если ваш аналитик выполняет только бизнес-анализ, то он возможно выполняет роль Product Owner и тогда всё хорошо — это чистый Agile.
Если ваши аналитики проводят системный анализ, то если разработчики с аналитиками образуют единую команду и единое информационное пространство (все концепции в голове аналитика, также есть и в голове у разработчиков, а аналитик в свою очередь многое знает о реализации), опять же всё хорошо — это чистый Agile, аналитик внутри команды.
Если же у вас есть барьер между аналитиками и разработчиками и аналитики выполняют системный анализ, то можно попытаться устранить этот барьер, а можно и перейти полностью на классический каскадо-водопад, с детальным ТЗ, спецификациями и проч., оставив барьер на месте.
Так и есть, я долго искал понятное определение Agile для себя, до этого было только интуитивное понимание. Так вот Agile — это когда разработчики и заказчик решают пойти по стопам кота Леопольда и говорят «давайте жить дружно». Т.е. работать как одна комманда со взаимопониманием и доверием — «мы не требуем от вас четкого ТЗ на весь проект, а вы не требуете от нас четкой оценки бюджета всего проекта, вместо этого работаем поэтапно, и вместе решаем проблемы». Кстати, когда решают «давайте жить дружно» разработчики и админы, из этого получается DevOps.
Пример того, как любое формальное следование чужим методологиям приводит к «культу карго».
Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?
Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?
Крупная компания, видимо, госкомпания, либо их дочка. Госкомпании вынуждены работать по каскадной модели. Плюс техзадание у них это вообще не техзадание, а бог знает что, хоть и соответствует гост 34 602. Почему? потому что цель техзадания — это получить предсказуемый результат в тендере, а не продукт, и не, тем более, достижение цели проекта. В госпроектах продукт owner это вообще мифический человек. И в результате — ни гост, ни prince2 (хотя в вышеприведенном примере ну просто напрашивается), ни agile, а банальный кавардак, ccmi уровня ноль, где хоть какой-нибудь результат достигается героическими усилиями отдельных лиц. Но истинная беда для разрабов, что там, где недостаток управляемости, там пытаются компенсировать нажимом руководства…
Описание типичного карго-культа.
Кхм… Ну вот изоляция разработчиков от заказчиков (в моём случае — не глухая, но всё же есть) — это такое благо… Вот никакого желания общаться с представителями заказчика напрямую не возникает (как с не очень квалифицированным персоналом — пользователями системы, так и с, по-идее, вполне квалифицированными специалистами-разработчиками заказчика, работающими над связанной подсистемой).
В общем проблема-то не в пунктах, а в их реализации…
В общем проблема-то не в пунктах, а в их реализации…
Испорченный телефон никто не отменял.
Если хочется получать деньги и не напрягаться, то с заказчиками можно и не общаться.
Если хочется приносить пользу людям, делать реально полезный продукт, то общаться надо.
Если хочется получать деньги и не напрягаться, то с заказчиками можно и не общаться.
Если хочется приносить пользу людям, делать реально полезный продукт, то общаться надо.
За счет чего продукт станет менее полезным, если с заказчиком будет общаться только аналитик, структурировать хаотичную информацию, приводить ее в понятный вид и обсуждать это все с разработчиками в спокойной обстановке?
А аналитик — не разработчик? :-)
Ну и для части коммуникаций аналитик или менеджер не нужны, сообщать о неработающих кнопках или технических проблемах вполне можно сразу ответственным за это людям. Конечно, если коммуникации нормально налажены.
Ну и для части коммуникаций аналитик или менеджер не нужны, сообщать о неработающих кнопках или технических проблемах вполне можно сразу ответственным за это людям. Конечно, если коммуникации нормально налажены.
Под разработчиками я имею в виду именно пишущих код людей. А обязанность аналитика как раз заключается в сборе, анализе и структуризации требований от заказчика.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
В Agile, Product Owner выполняет бизнес анализ и является ответственным лицом за коммуникацию со стэкхолдерами. Таким образом, он значительно снижает нагрузку на команду связанную со взаимодействием. Но, у команды остается возможность самой взаимодействовать со стэкхолдерами для проведения системного анализа, проектирования пользовательского интерфейса и архитектуры системы.
Все равно ХХивП всех победит! :)
UFO just landed and posted this here
я так понимаю проблема исключительно в аналитиках, которые должны были уменьшать неопределённости и помогать программистам, а получилось ровно наоборот. Аналитиками почувствовали себя важными, у них началась звездная болезнь и они начали работать не над решением проблем, а над повышением собственной значимости.
Это никак не зависит от модели ЖЦ проекта, я видел ровно такую картину при строго водопадной разработке.
Проблема решается очень просто — нужно чтобы аналитики отвечали перед разработчиками за качество своей работы.
Это никак не зависит от модели ЖЦ проекта, я видел ровно такую картину при строго водопадной разработке.
Проблема решается очень просто — нужно чтобы аналитики отвечали перед разработчиками за качество своей работы.
Никто не должен ни перед кем отвечать. Agile — это когда все работают вместе (каждый на своем участке), за факап одного отвечают все, и таким образом все заинтересованы в помощи друг другу.
Вы неправильно понимаете слово «отвечать». Суть в том, что каждый участник проекта создает артефакты, которые потом валидируются другими участниками. Например программисты создают приложение, которое потом проверяют тестеры и с ним работает заказчик.
А вот с аналитиками беда: простой текст — довольно плохой носитель сложно структурированной информации, а всяческие нотации обычно не понимаются всеми. Поэтому рабочие документы, которые рождает Аналитик практически никто не может провалидировать, кроме программиста. А программист, который не общается с заказчиком, тоже не может сделать этого в полной мере. Да еще и при модели, когда программисты не общаются с заказчиками программисты оказываются ниже «в пищевой цепочке» и стоящие выше аналитики не должны их спрашивать.
Вот и получается, что аналитик может сделать что угодно и не получит по факту никакого фидбека на свою работу, это и создает ситуации, описанные в посте.
А вот с аналитиками беда: простой текст — довольно плохой носитель сложно структурированной информации, а всяческие нотации обычно не понимаются всеми. Поэтому рабочие документы, которые рождает Аналитик практически никто не может провалидировать, кроме программиста. А программист, который не общается с заказчиком, тоже не может сделать этого в полной мере. Да еще и при модели, когда программисты не общаются с заказчиками программисты оказываются ниже «в пищевой цепочке» и стоящие выше аналитики не должны их спрашивать.
Вот и получается, что аналитик может сделать что угодно и не получит по факту никакого фидбека на свою работу, это и создает ситуации, описанные в посте.
Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;
Разработчикам уносить ноги надо из таких «молодых и небольших компаний». Тут по одному абзацу понятен уровень развития менеджмента.
Мы в компании с самого начала используем вариант с аналитиками, пока полет нормальный.
Попробую высказать ИМХО, по вашим проблемам:
>>> От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода.
Решается выделением тим.лида, тех.лида, архитектора и т.д. Т.е. человека, кто продумывает реализацию проекта, до такого как начать писать код, дальше разработчики в рамках его концепции решают задачи. Им ну нужно понимать все, нужно знать только свой участок работ и смежные вещи. За них вопрос понимания, с создания концепции решает другой человек.
>>>Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;
Это реально может быть проблемой. Но в данной ситуации нужно или качать знания аналитиков, или подключать человека из пункта выше к обсуждению задачи реализации и обсуждению ТЗ
>>>Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;
Имейте 2х сильных аналитиков в конторе, чтобы можно было одного заменить другим в случае необходимости.
>>> Разработчики и как не странно аналитики были демотивированы. Часто вспыхивали конфликты. Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!
Это полный трэш. Если аналитик не может разжевать задачу и ответить на все вопросы разработчика, гнать его надо! Если вопросов много или повышай качество передачи информации разработчику или сиди с ними пока не сможем все рассказать.
>>>Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).
Что значит не хотел? У ПМа работа такая брать ответственность на себя. Не хочет работать — до свидания!
Попробую высказать ИМХО, по вашим проблемам:
>>> От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода.
Решается выделением тим.лида, тех.лида, архитектора и т.д. Т.е. человека, кто продумывает реализацию проекта, до такого как начать писать код, дальше разработчики в рамках его концепции решают задачи. Им ну нужно понимать все, нужно знать только свой участок работ и смежные вещи. За них вопрос понимания, с создания концепции решает другой человек.
>>>Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;
Это реально может быть проблемой. Но в данной ситуации нужно или качать знания аналитиков, или подключать человека из пункта выше к обсуждению задачи реализации и обсуждению ТЗ
>>>Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;
Имейте 2х сильных аналитиков в конторе, чтобы можно было одного заменить другим в случае необходимости.
>>> Разработчики и как не странно аналитики были демотивированы. Часто вспыхивали конфликты. Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!
Это полный трэш. Если аналитик не может разжевать задачу и ответить на все вопросы разработчика, гнать его надо! Если вопросов много или повышай качество передачи информации разработчику или сиди с ними пока не сможем все рассказать.
>>>Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).
Что значит не хотел? У ПМа работа такая брать ответственность на себя. Не хочет работать — до свидания!
Sign up to leave a comment.
История одного факапа или почему итеративность — это необходимое, но не достаточное условие для Agile