Счастливый ProductOwner — верхом на пороховой бочке

    Вы — руководитель проектов и вам поручили создать сложный интернет-магазин с извращенным биллингом за 4 месяца. Вам хочется работать в этой компании ближайшие 2-3 года — платят хорошо, проекты громкие. Топы верят в вас. На кону ваша профессиональная репутация.

    Разберем, какой оседлать собственное подразделение разработки и добиться успеха.



    Процесс

    Если у вас есть полномочия и достаточно энергии — используйте Agile/Scrum в негуманной редакции. Если дело пойдет не туда — можно довернуть гайки и перейти в облегченный RUP, добив коммунизм ядерным ударом. Сейчас некогда разводить бюрократию и писать ТЗ на 1000 страниц.

    Что делаем?

    Нужно собрать требования по проекту. Быстро и основные. К сожалению, большое количество людей в компаниях в нашей стране, как правило — профанируют занимаемые должности. А умных людей, к счастью, подавляющее меньшинство. Если будете задавать профильным специалистам вопросы в лоб о том, как устроен их рабочий день, который интернет-магазин должен автоматизировать — приготовьтесь побороть желание придти на работу с бейсбольной битой и начать крошить тунеядцев.

    Не советую задавать прямые вопросы руководителям отделов — наживете себе злейших врагов — еще бы, вы открываете тайну, что сотрудники в их отделах… не знают чем занимаются :-)

    Если вам так не повезло, ищите любыми способами адекватного аналитика для сбора требований и охраняйте его жизнь. Постарайтесь найти поддержку у топов. Не найдете — увольняйтесь.

    Иногда в компании все же удается собрать требования к проекту.

    Сводим воедино

    На базе собранной информации делайте несколько артефактов чрезвычайной важности:

    1) Глоссарий. Это слово = значение. Если его не сделаете, не сможете дальше общаться с «умными» сотрудниками из отделов, не сможете понять аналитика и вас не поймет разработка, в которую скоро пойдем.

    2) Логическая модель данных — это квадратики-слова из глоссария и показанные отношения между ними (1 — *, * -*, 1 — 1). Данный инструмент проходят наши дети в школе сейчас при изучении логики. Самое сложное — расставить правильные отношения и выявить сущности.

    3) Прототипы интерфейсов. Отрисуйте с аналитиком от руки или от ноги прототипы страниц веб-сайта. Без деталей.

    4) Если дело пошло и вам и аналитику все понятно — выявите роли и их действия. Просто в табличке перечислите. Если не пошло — не беда.

    Ахтунг. Самое сложное — нужно свести все воедино. Тратим 1-2 полных дня. Можно на стене, доске. Происходит чудо — вы увидите основные части системы целиком. Если сами не увидите — постарайтесь, чтобы увидел аналитик, дайте ему премию :-). Это очень важно.

    Теперь нужно постараться, чтобы эксперты из других отделов увидели то же самое и согласовали с вами логическую архитектуру системы. Звучит смешно и глупо. Но иногда везет Да, люди будут включать дурачка, делать вид что не оканчивали школу… — вранье, любой человек способен описать термины, связи между терминами и свою роль в общей системе. Помогите им в этом, подключите топов :-)

    Если вам повезло и удалось заставить людей задуматься, возможно впервые в жизни — отправьте аналитика в отпуск, он заслужил.

    Планируем релизы

    Логический позвоночник продукта вы увидели — это 50% успеха. Дальше дело техники. Идем к разработчикам. Распределяем фичи на сложные/средние/простые с заранее определенной средней оценкой каждой категории.

    Если фич больше пятисот — включайте в команду второго аналитика, иначе сойдете к черту с ума и сведете туда же разработчиков.

    Программисты значительно лучше оценят фичи, если увидят прототипы интерфейсов, глоссарий, лог. модель данных, роли и задачи. А этом мы сделали.

    Не рекомендую проводить шоу под названием StoryMapping — если только в ваши задачи не входит развлекать людей и создавать атмосферу тусовки. Инструмент с размазанной формальностью думаю подходит только для простых систем или… гигантских систем.

    Самые приоритетные фичи включаем в первый релиз. В результате получаем грубый план релизов проекта. Объявляем жесткую дату запуска каждого релиза и проекта в целом.

    Специальные релизы

    Настоятельно рекомендую включить одним из окончательных этапов проведение нагрузочного тестирования на тестовых данных. Иначе можете запустить проект, а он… загнется через 2-3 дня.

    Еще очень полезен релиз качества — проводится комплексное бета-тестирование внутри компании. Снова проверяем весь функционал.

    Выбираем точку отсчета

    Важный момент. Вам нужно определиться и принять обоснованное решение:

    Пишем с нуля

    Если ваша задача — прокачать программистов, рекомендую писать проект… с нуля :-). Если вам нужно запустить интернет-магазин через 4 месяца — забудьте этот пункт как страшный сон.

    Правда если пойдете по этому пути — станете другом программистов вашей команды, будут здороваться с вами в коридорах. Еще бы — дали людям такую возможность прокачаться :-)

    Пишем с «единицы»

    Начальник разработчиков (если он прячется за командами, найдите его обязательно — такой в компании всегда есть) может предложить сократить время разработки за счет использования «низкоуровневого» фреймворка. Для PHP их несколько: ZendFramework, Yii, Symfony, CakePHP…

    Выбираем или нет? Дам совет — если пишите уникальную сложную систему, обрабатывающую большие объемы данных и обслуживающую миллионы посетителей в сутки (типа FaceBook ;-)) — выбирайте низкоуровневый фреймворк, не пишите с нуля. ZendFramework — как раз рассчитан на энтерпрайз класс задач.

    Дело в том, что опытных программистов очень и очень мало, особенно в нашей стране, а низкоуровневые фреймворки пишут как раз такие люди, поэтому не рискуйте и используете их наработки.

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

    Но наша задача — за 4 месяца запуститься :-) Поэтому фреймворк нас скорее всего не спасет.

    Пишем на базе коробочного решения

    Тут первая ключевая задача — понять, как работает коробка и ложиться ли ее логика в вашу задачу создания интернет-магазина с извращенным биллингом. Рекомендую разобраться самому и заставить разобраться аналитику. Если окажется, что подходит — вам повезло.

    Вторая ключевая задача — убедиться, что команда разработки сможет на базе коробки сделать вам проект в срок. Если коробка имеет хорошую техдокументацию и систему бесплатной/платной сертификации разработчиков и можно обучить людей работе с ней за две-три недели — шансы на успех значительно возрастают.

    Большой минус — разработчики скорее всего перестанут с вами здороваться. Им придется работать и решать четкие бизнес-задачи путем доработки ЧУЖОГО кода — а это очень бьет по мотивации начинающего программиста. Все хотят творить реальность самостоятельно :-)

    Выбор коробочного решения… Если у вас очень сильная и опытная в ООП команда разработчиков, со средней зарплатой по москве в районе 100к и в команде человек эдак десять — для навороченного магазина неплохо подойдет Magento.

    Если же вы ограничены в ресурсах и сроках (3 разработчика, 3-4 месяца) и ожидаете, что кроме функциональности интернет-магазина скоро или уже требуется обеспечение технической поддержки клиентов, сервисы опросов, форумы, блоги, встроенный поиск, интеграция с 1С, поддержка российских платежных систем, если хотите после запуска проект САМОСТОЯТЕЛЬНО через админку управлять сайтом, не привлекая программистов для малейшего изменения функционала — тут разумеется коробка от 1С-Битрикс вне всяких конкурентов. Вы запуститесь в срок и ближайшие 2-3 года будете плевать в поток — управляя сайтом через админку без привлечения разработчиков.

    Более того, если вы не хотите ругаться с командой разработки по поводу «почему стал тормозить интернет-магазин, клиенты жалуются» или «почему интернет-магазин вчера не доступен был с 9 до 11 утра» :-) — СРАЗУ создавайте проект по типу веб-кластера — благо в вышеупомянутой коробке есть такая возможность.

    Программисты вашей команды взвоют от использования любой коробки и устроют вам темную :-) Мне помогал такой фокус — для самореализации программистов я просил сложные задачи делать на базе крутого низкоуровневого фреймворка, например ZendFramework. В итоге и овцы оставались целы, и волки сыты.

    Делаем спринты

    В ваших шкурных интересах — качество выполненных за спринт фич. Из-за отсутствия жесткого водопадного цикла контроля качества вы рискуете нарваться на быструю разработку фич фекалийной консистенции.

    И не думайте, что если будете долю времени в спринте тратить вместо реализации фич на написание командой юнит-тестов, это спасет вас от погружения в болото безобразного качества. Юнит-тесты нужно УМЕТЬ писать, а найти таких людей — сложно.

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

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

    Качество — это системный, а не эмоциональный процесс. Задачу нельзя решить на том же уровне, на котором она возникла. Пока не будут приняты системные меры в разработке: настроен трекер, внедрено Continuous Integration и т.п. — дальше не идете, спринт не принимаете, конвейер стоит.

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

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

    Нагрузочные спринты

    Для контроля того, что проект будет работать с ожидаемыми объемными данными, после реализации крупной фичи в серии спринтов — проведите ее нагрузочное тестирование, не откладывая на потом. Если окажется, что система висит и не обрабатывает ожидаемый объем данных — собирайте совещание с рук. разработки/техдиром и устраивайте разбор полетов. Пока не будут приняты системные меры — конвейер остановлен, спринт не принимается. Опять таки — такие системные задачи, как качество архитектуры и программирования — плохо решаются на уровне ретроспектив. Решайте на более высоком уровне.

    Аналитик — ваш друг

    Поручите аналитику тщательно проверять, что поставленные на спринт в фичах и дополнительно прокомментированные в логической модели данных, прототипах интерфейса и глоссарии требования — выполнены в полном объеме, как продуманно и написано. К сожалению, часто приходится тащить и доделывать ДО КОНЦА КАК НАПИСАНО фичи из одного спринта в другой.

    Фиксируйте время, потраченное на «доделку» фичи, связанную с невнимательным чтением описания требования. Если процент безалаберности в команде возрос до критического уровня — ищите руководителя разработчиков/скрам-мастера и… бейте — это его задача обеспечить дисциплину в командах.

    Экспериза оценок

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

    Корректировка процесса

    Чем хороши гибкие методологии типа Scrum — так это открытостью процесса. Если не получается и проект заваливается — это видно всем, видно хорошо. Может оказаться, что:

    — разработчики в команде оказались слабыми и неопытными
    — скрам-мастер оказался тряпкой, лидера в команде нет, тусение и раздолбайство, которое выражается в недочитывании требований до конца, халтуре и многочисленных багах
    — технический директор скрывается от вас, считая что ваша задача заниматься воспитанием программистов :-)

    Можно закрутить гайки в направлении упрощенного RUP:

    — С аналитиком пишите ТЗ на итерацию
    — Оцениваете ТЗ с руководителем отдела разработки/техдиром
    — Разработка тщательно тестирует своими силами результаты итерации, демонстрируя успешное выполнение юнит-тестов (хотя бы на момент приема работы)
    — Тщательно принимаете выполненную работу, вам помогает в этом также аналитик

    Да. Это будет уже война капитализма с коммунизмом. Но шанс победить и запустить интернет-магазин, правда не за 4 месяца, а за… год, остается :-)
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +4
      Подтверждаю, на практике оно именно так все и происходит :(.
        +2
        Ну почему же именно так, иногда и веселее бывает :)
          0
          Еще «радует», когда вы с аналитиком увидели систему целиком и формально и точно ее описали — а разработчики… отчаянно тупят и вы, сопротивляясь врожденному гуманизму, вынуждены толкать «мозги нации» в з… цу, прошу прощения
            0
            Самое смешное в этой ситуации что если спросить у разработчиков — все получится наоборот =)
              0
              Погодите. Аналитик описывает бизнес-процессы и логику и работает на уровне выше. Разработчик эти вещи переводит на уровень ниже — уровень классов и таблиц БД. Односторонний процесс.

              Да, если аналитик попадется тупой или менеджер глупый — то тут разработчики могут реально посоветовать дело :-)
                +1
                Вообще я это к тому писал, что если послушать разные стороны — у каждого своя правда будет.
        +6
        Написано от души!
          +1
          По большому счёту, глоссарий + ER + прототип покрывает бОльшую часть того, что пишется в тысячестраничном ТЗ. Разумеется, если в прототипе у каждого контрола подписано, какому полю какой сущности из ER-ки он соответствует и словами описаны принципы выборок и поведения кнопок. Совокупность ER и протототипов намного более защищена от разночтений, чем объёмистое ТЗ. Собственно, ругать разработчиков за то, что они невнимательно прочитали ТЗ — дело правое, но неблагодарное, поэтому лучше рисовать.
            0
            Еще иногда нужно описать алгоритмы, например расчета скидок. Можно в виде Activity диаграммы, можно через State диграмму, можно в ТЗ словами конечно.

            Иногда разработчики модели не досматривают до конца :-) Кардиналити реализуют не так, как нарисовано. А еще страшнее, шепотом — когда дело доходит до ссылочной целостности на уровне приложения — у меня один раз спросили перед сдачей проекта несколько лет назад в другой компании, а что это?
            +1
            А я еще добавлю. Если вы программист/разработчик в такой команде (где на 3 программистов 2 бездельника: техн. директор и менеджер/аналитик) — валите пока не поздно. От работы по перепиливанию магентовского/друпаловского/джумловского/вордпрессового/битриксовского кривокода ничего хорошего не выйдет, не будет ни роста профессионального уровня, ни хорошего настроения. Вы либо станете мартышкой за клавиатурой, либо впадете в депрессию (хоть я и не верю, что она вообще существет в природе, но все же).

            Ну и насчет Zend Framework в высоконагруженных проектах — sounds weird, ни вконтакт, ни фейсбук не используют, да и я бы не стал использовать, так как он слишком универласелен, вы будете использвоать 5% возможностей, а вот тормозить все это будет на все 100. Общая идея и концепции в нем хорошие и интересные, но в реальности использовать вместе с тормозным скриптовым языком еще и монстроподобный фреймворк… тут никакой сервер не потянет. Плюс, многие компоненты сделаны ужасно, формы и View например.
              +4
              Если программист сможет разобраться в коробочном продукте — он приобрает хороший системный опыт выживания в море кода. Не все это могут, некоторые ломаются и остаются на уровне пары тройку классиков.

              Под юникс пишут же софт — приспосабливаются :-) А что, юникс правильно написан на ООП — нет.

              Под j2ee чтобы писать правильно нужно дофига изучить готового кода и прочитать массу книг. Своего рода тоже коробка.

              Я лично знаю много отличных разработчиков, владеющих ООП и паттернами проектирования, которые смогли разобраться и научились уважать коробки. Мало того, коробочная разработка приносит ребятам неплохой доход, в отличие от крутого ООП… для души.

                +4
                Про Zend заявление в стиле — не писал, но осуждаю. Про facebook и vkontakte — а еще они патчат ядро ОС, пишут свои веб-сервера и БД, давайте тоже начнем разработку с этого. Не надо сравнивать жопу с пальцем.
                  0
                  Я писал на Zend Framework. При чем тут патчи ядра? Я говорю о сложной логике приложения.
                    +2
                    Я отвечал предыдущему оратору
                +2
                Я что то не догнал. За пол года на Rails, да еще силой нескольких человек можно запустить какого-то просто монстра. Не понял в чем подвох про «4 месяца». Ну только если на этапе согласования дизайна с заказчиком будет пипец.

                Во вторых — если в начале нет подписанного ТЗ — а как организовать сдачу проекта? Ну понимаете, бюджет обозначен, значит заказчик попытается все что можно трактовать в свою пользу. Если у вас нет ТЗ, то тут то, на этом самом этапе вы и выбьетесь из срока — потому что при виде реальных вещей у клиента обычно просыпается креатив «а еще было бы клево добавить это» — вот тут то да, хорошо если за год закончите. Хорошо если не разосравшись с клиентом по поводу счета за работу.
                  0
                  Я тут про php писал. ТЗ… хотелось же по хорошему, по человечески, по Agile методологии.

                  Если коробка то тут можно аккуратно без большого ТЗ. В ТЗ вписываем только то, что нужно в этой коробке доделать/переделать. Если коробка имеет документацию, то на нее ссылки из ТЗ.

                  Поэтому показываю, что за 4 месяца можно и магазин написать и ТЗ большое не делать :-)
                    0
                    Да, большое «бюрократическое» ТЗ, как правило, не нужно.

                    Тут цель ТЗ — скорее убедиться что вы правильно поняли заказчика, и описать все на русском языке. Потому что изменять ТЗ на начальном этапе все таки проще, чем переделывать код в конце.

                    Скорее, это все таки страховка, позволяющая избегать затягивания проекта под конец — заказчик должен понимать свою ответственность за свои хотелки.
                  +1
                  Та часть которая от КО (про глоссарий, про аналитиков, про опросы, про квадратики со стрелочками, и даже про преимущества готовых решений) — да всё хорошо и правильно. Но как только начинаются эмоциональные оценки и «юморок из презентаций 'гуру'» — впечатление резко портится.
                  Вот была компания, работала. В ней был отдел разработки и тоже работал. И всё у них было не то чтобы прям очень хорошо, но в среднем — неплохо. И вот появился в компании новый манагер проектов которому поручили за 4 месяца открыть интернет-магазин. Он взялся за дело и делал в целом всё не плохо. Но вот в какой-то момент, вместо того чтобы решать проблемы и двигаться к результату, он начал «дёргать рубильники», «требовать кадровых перестановок», и всячески показывать что он то «за дело», и всё бы хорошо но вот только разработчики халтурят, бездельничают, проще говоря «Козлы». Естественно — начальнику разработки «козлом» быть не хочется. И тут начинаются чудеса — в ТЗ находится много ошибок и каждая ошибка постфактум начинает раздуваться как оч серьёзная, из-за которой все сроки и сорваны. Да и начальники других отделов — не бездельничают (как могло показаться из картинок манагера и аналитика), а работают в поте лица. И вот вся эта братия совместными усилиями проект разваливает + ведёт информационные войны с понятной целью.
                  В итоге — магазин не запущен, манагер уволился. Печаль.

                    0
                    Я понимаю вас. Создается техническая мафия, которая вяло, ковыряясь пальцем в носу, поделывает пописывает проекты. Конечно, когда приходит управленец, который снизу подсвечивает безответственность и разгильдяйство — его не любят, особенно если получают неплохие деньги за процесс, который и так идет. :-)
                      0
                      Тут ведь всё относительно и у каждого участника тех событий окажется своя правда и тысячи аргументов в поддержку своей версии.
                      Просто из поста складывалось ощущение что «крутой нрав» — одно из слагаемых успеха. Я хотел показать что это вполне может быть не так. Один в поле не воин и в ситуации, когда «манагер» попытается выставит всех идиотами и бездельниками — поставленной цели он может и не добиться. Особенно когда на стороне «идиотов» месяцы/годы совместной б.м. нормальной работы.
                      Более гибким надо быть. Стремление «в лоб» убедить людей в том, что они ничего не делают или публично это показать — позитивных результатов не принесёт, а отношения испортит и сделает достижение цели ещё более сложным. Ведь мало кто готов помогать в решении проблем человеку, который вчера перед «генеральным» пытался выставить весь отдел идиотами.
                        0
                        Согласен. Не верю, что без системного подхода можно браться за сколь серьезные проекты. В статье старался описать выстраивание системы управления — открытой и честной. Ну сделали мне спринт фекалийного качества — давайте собираться и смотреть в чем дело, разбирать полеты.
                          0
                          Но есть момент. Иногда попадаются группы людей одного уровня — средне-низкого, спаянные тусением и взаимным раздолбайством. И им бесполезно что-либо доказывать, показывать, объяснять — в этом случае нужно решать проблему на уровне выше.
                      +2
                      Да, до боли знакомые процессы. Вообще agile методологии хорошо подходят в плане гибкости сроков, оплаты и взаимоотношения с клиентом. Потому что наперед выдается продукт и заказчик быстрее видит результат, проще вносить какие-то изменения. Раньше я больше к RUP склонялся, импонировала изначальная четкость задач, но со временем такой подход стал костью в горле )

                      Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.

                      Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.
                        0
                        Зато какой накал страстей! Спасибо за совет, плюсую.
                          +1
                          Экстримально да и Джоэл Спольски, наверное бы, поспорил с данным методом, но для удаленной работы вполне может работать хорошо. Вот его цитата:

                          Предположим, вы решили награждать разработчика с наименьшим количеством багов. Теперь каждый раз, когда тестировщик пытается сообщить об ошибке, это превращается в большой спор, и, как правило, разработчик убеждает тестировщика в том, что на самом деле это не баг. Или тестировщик соглашается сообщать разработчику о багах «неофициально», перед тем как вносить их в багтреккинговую систему. И никто больше не пользуется багтреккинговой системой. Число ошибок снижается, но на самом деле их остается столько же.
                          Разработчики очень сообразительны в этом отношении. Что бы вы ни пытались измерить, они найдут способ оптимизировать этот показатель, и вы никогда не получите именно то, чего пытаетесь добиться.
                            –1
                            Ну я не пробовал, конечно, но думаю и в офисной работе это можно решить чисто организационными и техническими методами. Устранив допустим взаимодействие между тестерами и программистами, снизив до минимума взаимодействие между сотрудниками вообще как это бывает при удаленной работе. Каждый должен быть сам за себя, коллективизм тут во вред.

                            Хотя может для классической офисной работы такой вариант и не покатит, было бы интересно услышать мнения опытных офисных менеджеров и руководителей на этот счет, а ещё лучше произвести эксперимент )
                          0
                          Простите, но вы описываете процесс так, будто задача должна быть реализована за 1 месяц, а не зна 4.
                          Я откровенно не понимаю, что можно писать 4 месяца в 4 пары рук на фреймворке. Точно, что фейсбук можно написать, вместе с апи и соц графом. Я привык к другим темпам разработки…

                          Ну а так, в целом, где-то так и есть. Кстати, обычно, даже при наличии ТЗ, все равно процесс сваливается в agile. Это, наверное, скверно, но почему-то так почти всегда…
                            +1
                            Ну да, по всем оценкам на покере релиз на коробке должен завершиться за 4 спринта — но, черт, появляются спринты под названием «Стабилизация», «Углубленное тестирование», «Исправление багов», «Тестирование после исправления багов», «Разгон системы, зависшей после исправления багов» — я совершенно серьезно. И поэтому тут и 4 и 6 месяцев и… год может пройти :-)
                            +2
                            а мне показалось, что статья была написана ради одной фразы)
                            хотите после запуска проект САМОСТОЯТЕЛЬНО через админку управлять сайтом, не привлекая программистов для малейшего изменения функционала — тут разумеется коробка от 1С-Битрикс вне всяких конкурентов. Вы запуститесь в срок и ближайшие 2-3 года будете плевать в поток — управляя сайтом через админку без привлечения разработчиков.
                            может быть поэтому весь остальной антураж из модных словечек выглядит притянутым за уши?..

                            все и так знают, что фейсбук написан на ZendFramework, ООП сочинили разработчики для прокачивания зряплаты, а юнит-тестирование — чтобы затягивать разработку на год. но вообще, после такого заявления, я надеялся, что будет презентация десятка интернет-магазинов, которые после 3-4 месяцев разработки по предложенной схеме, уже 2-3 года успешно работают без привлечения разработчиков, управляемые через админку счастливым PO… или хотя бы пару… ведь где-то они существуют?)

                            остальное и так очевидно. Agile придумали разработчики для того, чтобы PO можно было не составлять ТЗ. чудесный Scrum даётся им в награду за лояльность и прилежность (иначе будет RUP). не поянтно, зачем тратить месяц аналитики на составление глоссария, E-R модели, прототипов интерфейсов, когда в итоге PO ратует за коробку вне всяких конкуретнов, которая все равно навяжет собственное решение, включая терминологию, архитектуру и интерфейсы?

                            понятно — аналитик лучший друг PO и ему через месяц нужно на что-то ехать в отпуск. вероятно он уже избит настолько, что не в силах решать _задачи_ на том уровне, где они возникают. но неужели лучший друг запарился настолько, что путается в собственных терминах? я не знаю, что ему рассказывали ваши дети после уроков логики, но E-R всю жизнь была концептуальной моделью, а не логической. логика это формальная система, а не просто набор популярных мемов -)
                              0
                              Я не писал про E-R модель :-), если читали внимательно.

                              Одна из целей статьи — объективно показать PO когда коробочное решение действительно может принести ему выгоду. А когда не может.

                              Список успешных решений на коробках можете посмотреть в моем портфолио — я не хочу грузить маркетинговым булшитом уважаемых коллег :-)

                              Мемы и другие техники манипулирования сознанием — не приветствую. Предпочитаю делиться личным опытом и наблюдениями.
                                0
                                >> а мне показалось, что статья была написана ради одной фразы)

                                Человек там работает все-таки. Не мог не упомянуть :)
                                  0
                                  Кем я только не работал :-) Зато изучил всю кухню снизу вверх в деталях, о чем и рассказываю.
                                0
                                Очень хорошая статья, спасибо автору.

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

                                Потому что успеха проекта не предвидится. Но, кстати, может оказаться так, что зп вы будете получать и после неуспеха проекта )
                                  0
                                  Спасибо. По секрету, тсс..., если вы видите что топы, как бы мягко это сказать, замедляют процесс развития компании и тролят — их можно подставить и лично встретится с первым лицом компании. Вас либо быстро уволят за это — либо вы станите топом и воплотите здоровые идеи в жизнь. :-)

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

                                Самое читаемое