Управление компанией-разработчиком: оно вам надо?

    На Гайдаровском форуме Герман Греф заявил, что Сбербанк будет переходить на новые информационные технологии, выбрав в качестве основного партнёра российско-американскую компанию с численностью 60 чел. При этом Сбербанк потратил 65 млрд. руб. на амбициозный и сложный проект централизации ИТ- структуры и на сегодняшний день у него более 22 000 ИТ-сотрудников, включая 6 тыс. человек в Сбертехе. Основная причина перехода — скорость внесения изменений в ИТ, которая была низка и привела к отставанию ИТ Сбербанка от лидеров по развитию и гибкости ИТ-инфраструктуры. А насколько важна скорость внесения изменений в разработке? На что нужно обратить внимание в управлении процессом разработки? Стоит ли использовать модели и методологии? Попробуем разобраться.


    В окружении


    Когда разрабатываешь свою автоматизированную систему управления (АСУ) сталкиваешься с некоторыми вопросами с двух сторон. Например, с одной стороны сам управляешь процессом разработки, а с другой — адаптируешь свою XRM (например, Ruli24) для компаний, желающих её использовать как инструмент управления их разработкой (девелоперские компании, партнёры компаний по доработке). Кроме того, что в систему закладывается учёт временных ресурсов и планирование задач, нужно правильно оценивать то окружение, с которым приходится работать.



    На упрощённой схеме ИТ-инфраструктуры компании все элементы разделены. Однако мы с вами прекрасно знаем, что в реальной жизни «чистый профиль» встречается редко и чёткого разделения функциональных обязанностей нет. Собственно, в этом нет ничего плохого, более того, в последнее время набирает популярность DevOps, подход, подразумевающий «гибрид» разработчика и администратора и быстрое развертывание и тестирование релизов. Именно ввиду вот таких функциональных пересечений управление разработкой выходит на первый план.

    Прежде, чем перейти к моделям, методикам и методам, обозначим цикл разработки, которым предстоит управлять. Подходов к циклу существует огромное множество, мы же обратимся к стандарту ГОСТ 34.601-90.



    Мы неслучайно затронули эту тему — в нашей компании ИЛАДА назрела необходимость смены модели управления разработкой ввиду роста бизнеса и динамичности требований наших клиентов. Эксперты нашей команды тщательно проанализировали различные модели и методологии, взвесили плюсы и минусы. Сегодня мы готовы поделиться с вами материалом, а заодно выслушать в комментариях рекомендации, исходя из вашего опыта.

    Модели разработки — три кита управления


    ИТ-менеджмент и управление разработкой всегда стремились найти оптимальную модель. Модели эволюционировали вместе с технологиями и изменениями коммерческой составляющей разработки. Скорость изменения технологий, развитие бизнеса и постоянно меняющийся спрос оказали влияние на модели: от жёсткой каскадной мир разработки пришёл к итеративной модели и так называемой гибкой разработке. Однако, как и в любой науке, предшествующий опыт обязательно учитывался и лучшие практики всех моделей переходили в более современные. Выделим и вкратце рассмотрим три основные модели.

    Каскадная модель разработки (модель водопада): определение требований, проектирование, программирование, тестирование, внедрение, сопровождение. Разработчик, следуя этой модели, последовательно переходит от одной стадии к другой. Очевидно, что, несмотря на строгость подхода и чёткое выделение этапов, эта модель негибкая, отнимает много трудовых и временных ресурсов. Кажется, что каскадная модель в наше время должна была уже отмереть как непродуктивная, однако она продолжает жить и использоваться, правда, всё больше в государственных и оборонных структурах. Например, в проектах государственной важности в Германии принято использовать V-модель разработки, в основе которой как раз лежит каскадная. Этот выбор не лишён логики: такая модель может тщательно контролироваться и способна сократить большинство управленческих рисков. Однако государство редко работает в режиме жёсткой экономии и не вынуждено оптимизировать процесс любым путём — у него другие задачи. Современный бизнес выбирает иные модели.

    Итеративная модель разработки предполагает выполнение работ параллельно с непрерывным анализом результатов и корректировкой предыдущих этапов. Здесь процесс разработки предстаёт перед нами как цикл: планирование — разработка — тестирование — оценка. Эта модель выглядит привлекательно за счёт снижения рисков, работы в проектных командах, равномерного распределения нагрузки участников разработки, непрерывного тестирования и доработки. Пожалуй, это наиболее подходящая модель разработки корпоративного программного обеспечения, поскольку она предполагает взаимодействие с пользователем/заказчиком, позволяет использовать опыт команды и сокращает накладных расходы на разработку. С рыночной точки зрения продукт, созданный по итеративной модели, может быть дешевле аналогичного продукта, созданного с использованием каскадной модели.

    Спиральная модель, также подходящая для коммерческой разработки, особенно сложных проектов), соединила в себе преимущества прототипирования (создания минимально работающего опытного образца) и каскадной модели. Более того, на каждом витке могут применяться различные модели разработки, главное, чтобы заказчик максимально быстро получил работающее ПО. Фактически это разработка итерациями: не завершив один этап, разработчики приступают к следующему, на котором дополняются результаты работы на предыдущем витке. За счёт формирования плана разработки и жёсткого следования ему разработка ведётся довольно быстро. Такая модель помогает преодолеть такие проблемы управления компании-девелопером как нехватку рабочей силы, срывы сроков разработки и поставки ПО, изменения требований заказчика. Особенно успешно такая модель работает на крупных проектах, например, на внедрениях сложных дорогостоящих CRM и ERP, когда в процессе доработки и разворачивания системы у клиента со стороны вендора ограничены ресурсы (вся команда не может заниматься одним клиентом), а со стороны заказчика в любой момент могут поступать изменившиеся требования.

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

    Как выбрать модель разработки?


    Современные компании представляют собой универсальные организации, которые одновременно разрабатывают основной продукт, создают клиентские версии, проводят доработку и осуществляют внедрение. Соответственно, следование одной выбранной модели весьма затруднительно. Чтобы определить, какая модель подходит вашей компании, необходимо провести небольшое внутреннее обследование.

    • Кем себя позиционирует компания — разработчиком крупных заказных проектов, вендором (производителем) тиражного ПО, разработчиком уникального решения, разработчиком SaaS решения или разработчиком небольших проектов? А может она занимается проектами внедрения ПО?

    • Как долго длятся эти проекты: месяц, квартал, год, три года или десятилетия?

    • Каков состав команды? Какова квалификация?

    • Кто является клиентом? Готовы ли типичные клиенты работать на стороне разработчика и взаимодействовать на всех этапах или это пассивные наблюдатели, согласовавшие техническое задание и ожидающие результата?

    Ответ на эти вопросы формирует базу для принятия решения о выборе методологии. Так, например, крупные проекты, в том числе разработки для оборонки и промышленности, скорее всего выберут каскадную модель, которая позволяет самым глубоким образом проработать все аспекты взаимодействия технологий при разработке, разделить зоны ответственности и тщательно реализовать каждый этап. Думаю, что к каскадной или смешанной модели тяготеют и крупные разработчики и вендоры масштабных корпоративных и пользовательских решений: операционных систем (кстати, в случае Microsoft это MSF — сочетание каскадной и спиральной моделей), CRM, ERP, xRM.

    Для заказных решений и проектов внедрения отлично подойдут итеративная и спиральная модели разработки. Эти же модели, скорее всего, выберут стартапы, крупные сайты и порталы, социальные сети, то есть масштабные проекты, которые, однако, не тиражируются и не кастомизируются.
    Могу привести пример нашей разработки системы Ruli24. Для разработки версионных коробочных решений наша команда использует каскадную модель, для проектов внедрения и кастомных релизов — итеративную и спиральную модели. Что касается методологий, то мы ещё не выбрали окончательный вариант, однако построили систему управления разработкой, по духу схожую с agile, на базе Ruli24. Более того, именно работа над проблемой управления разработкой подтолкнула нас к созданию модуля управления процессами.

    Как это получилось?


    Очевидно, что весь цикл разработки укладывается в набор процессов:

    • Исследовательский процесс, в ходе которого проводится сбор требований, составляется техническое задание.

    • Процесс создания проекта, результатом которого является создание сперва прототипа, а затем и завершённого работающего программного обеспечения, готового к внедрению на стороне клиента. Этот процесс также включает верификацию ПО.

    • Процесс сопровождения проектов. Это ни что иное, как сервисная поддержка, HelpDesk, обрабатывающая запросы пользователей по установленным регламентам уровня сервиса. Запросы необходимо сортировать, аккумулировать, обрабатывать, на их основе формируется база знаний.

    • Проведение форумов и совещаний, связанных как с разработкой каких-то новых продуктов, с исследованиями, так и с тем, что происходит внутри компании по текущей деятельности.

    • Разработка новых версий ПО — стандартный бизнес-процесс компании-разработчика, он включает обычные этапы: проект создания версии, тестирование версии, поставку версии заказчику.

    Все действия последовательные, один процесс сменяется другим, сопровождается стандартным документооборотом, нуждается в контроле задач, сроков и планировании. Пока речь идёт о 10 клиентах и 5 проектах, все проблемы решаются устно и ведением записей на маркерной доске. Однако при разрастании проектов необходима автоматизация, причём такая, чтобы были увязаны все уровни процессов и управления проектами.

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

    Итак, модель выбрана, теперь нужна методология. Поговорим о них.

    Ловкая методология


    В последнее время невероятную популярность получили гибкая методология управления разработкой, так называемая agile-методология. Рассмотрим её подробнее и выясним, а всем ли она подходит.

    Само слово agile, пришедшее в английский из французского языка, означает «ловкий, проворный». Пожалуй, ни одно слово лучше не охарактеризует эту методологию. Как я уже упомянул, agile не включает в себя жёсткие правила или практики, а определяет ценности, которыми руководствуются команды, использующие эту методологию. На первый взгляд, основные идеи agile-методологии выглядят не вполне реалистично:

    • люди и взаимодействие важнее процессов и инструментов — кажется, что такой подход приведёт к разобщённости команды, нежеланию отвечать за результат работы;

    • работающий продукт важнее исчерпывающей документации — трудно представить себе сложную информационную систему, производственное ПО или, например, текстовый редактор без подробной сопроводительной документации;

    • сотрудничество с заказчиком важнее согласования условий контракта — для российских реалий этот пункт выглядит просто страшно: каждый разработчик боится непрерывного изменения требований со стороны заказчика;

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

    Однако многие команды, использующие agile, крайне эффективны и успешны. Эта методология, на самом деле, значительно упрощает разработку продукта. Уверен, что не в последнюю очередь это заслуга специфического подхода к формированию команды разработки и управлению этой команды: кроме архитектора, программистов и дизайнера в команду обязательно входят представители заказчика (его сотрудники или менеджер его проекта). Вот причины и ожидания от перехода на agile, перечисленные респондентами опроса Techbeacon:

    Усиление сотрудничества между командами, которые обычно не работают вместе — 54%
    Увеличение уровня качества программного обеспечения — 52%
    Рост удовлетворённости клиентов — 49%
    Сокращение сроков выхода продукта на рынок — 43%
    Сокращение стоимости разработки — 42%

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

    • Agile-подход позволяет иметь всегда актуальный продукт, соответствующий требованиям заказчика, поскольку методология предполагает принцип ответа на изменяющиеся требования заказчика. С одной стороны, продукт соответствует времени, с другой — клиент всегда получает именно то, что он хочет, а значит, у него меньше мотивов обратиться к команде конкурента.

    • Частая поставка ПО за счёт коротких спринтов обеспечивает команде возможность быстро разбирать беклог проекта и реализовывать самые приоритетные задачи.

    • Тесное взаимодействие с заказчиком на всех этапах проекта помогает верно трактовать техническое задание и в сочетании с короткими спринтами на даёт отойти от требований и создавать невостребованную клиентом функциональность.

    • Внимание к используемым технологиям и юзабилити значительно сказывается на качестве разработанного продукта. Проект постоянно адаптируется к новым тенденциям и запросам пользователей.

    • Самоорганизация команд, очное общение хорошо сказываются на производительности каждого из членов команды. Как показало исследование, agile не приживается лишь в 15% команд, которые его выбрали.


    С точки зрения бизнеса agile также кругом выгоден.

    • Он позволяет ускорить выход продукта на рынок и постоянно соответствовать требованиям рынка.

    • Продукт, создаваемый по методологии agile, создаёт впечатление крайне лояльного пользователям. например, можно собирать отзывы пользователей и закладывать их в спринт, постоянно отчитываясь об изменениях. Готовность изменяться значительно повышает авторитет проекта.

    • Agile помогает согласовывать ИТ (разработку и сопровождение) с целями бизнеса.

    • Несмотря на видимую демократичность, методология повышает общую производительность компании.



    Конечно, существует и негативный опыт использования agile. Он может возникнуть в трёх основных случаях.

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

    2. Команда не может самоорганизоваться и превращает agile в распущенность и пустую болтовню на совещаниях. Действительно, до 30% времени спринта уходит на собрания и совещания (перед спринтом 4-8-часовое собрание, после и каждый день не более 15 минут). Нужно донести до команды, что эти совещания — важная часть работы над проектом и их задача не обмен сплетнями и шутками, а собранное обсуждение проблем, задач и времени проекта. В конце концов, на кону удовлетворённость клиентов, доход компании и персональный доход каждого сотрудника.

    3. Снижение качества продукта за счёт небрежного отношения к технологиям разработки и особенностям ИТ-инфраструктуры. Действительно, бывает так, что команда, увлекшись юзабилити или дизайном, напрочь забывает о производительности, рефакторинге и тестировании на разных сборках. Здесь на помощь приходит менеджмент производительности, который также должен стать бизнес-процессом. О нём я расскажу чуть ниже.

    Scrum — толкучка разработчиков


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

    Scrum предполагает короткие итерации спринтами по 15-30 дней, во время которых команда максимально сосредоточена на разработке и в конце которых пользователь получает рабочее программное обеспечение с новыми возможностями, которые были выбраны из беклога проекта как приоритетные. Задачи по разработке функциональности не могут изменяться на протяжении всего спринта, а время строго фиксировано и его сдвиг является сигналом того, что команда не учитывает при планировании какие-то факторы. Чем короче спринт в scrum, тем гибче разработка — выбирая задачи из беклога, разработчики знают, что двигаются в правильном направлении и создают именно тот софт, который нужен заказчику.

    Основным источником информации о необходимых доработках и новой функциональности в scrum является беклог проекта, где все члены команды могут собирать любые требования. Этот список упорядочивается по степени важности каждого из изменений. Исходя из времени спринта и опыта команды наиболее приоритетные задачи попадают в беклог спринта — то, что будет реализовано в ближайший отрезок разработки и разбито на задачи для членов команды. Scrum-команда включает в себя архитектора, дизайнера, программистов, тестировщиков и представителя заказчика. Перед спринтом приводится 2-8-часовое совещание по планированию спринта, в ходе которого мотивированно отбираются задачи их беклога проекта и устанавливается длительность спринта. Большое совещание по итогам проходит и в конце спринта. Ежедневно проходят небольшие, до 15 минут, митинги по оценке текущего положения дел и необходимости корректировки действий. Всё это время строится Диаграмма сгорания задач — график, на котором отмечается количество сделанной и оставшейся работы. Чаще всего scrum-команда ведёт доски со стикерами, где передвигает задачи между этапами.

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

    Lean/Canban — scrum, который постиг дзэн


    Одним из вариантов scrum является методология бережливой разработки (lean) и Канбан. Они пришли в разработку из японской автомобильной промышленности, а именно из концерна Тойота, который широко известен своим подходом к бережливому производству и успешно использует систему карточек Канбан для сборки автомобилей без затоваривания склада и перегрузки цеха.

    Канбан, как и scrum — это не бизнес-процесс, не действие, а система ценностей разработчиков, методология. В процессе Канбан команда работает над задачей от начала и до конца, установок сроков выполнения задачи нет. В этой методологии важно уметь правильно расставить приоритеты при выполнении задач.


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

    Подходит ли вам agile?


    Agile сам по себе довольно продуманная методология, однако не следует её принимать за единственную истину. Прежде, чем обратиться к той или иной методологии, точно так же, как и в случае с моделями важно определить, какой подход к вправлению будет наиболее результативным именно для вашей компании. Возможно, стоит вести разработку по строгим ГОСТам времён СССР с тщательным оформлением ТЗ и созданием технического проекта, а может, пора купить доску, стикеры и познакомить команду с Канбан.

    Agile удобно использовать, если у вас:

    • Требования к проекту определены нечётко или постоянно меняются по желанию клиента или в результате конкурентной разведки.

    • Характеристики будущего продукта подвержены большой волатильности.

    • Нет времени на подготовку формальной документации по проекту, приходится работать «на лету».

    • У исполнителя и заказчика повышенная толерантность к риску.

    • У вас есть возможность создать сплочённую и эффективную команду для управления разработкой.

    • Ваш продукт легко бьётся на модули, которыми могут заниматься agile-команды.

    Это далеко не полный перечень условия для успешного старта agile, однако перечислены наиболее характерные признаки. Вообще, можно применять различные методологии и сочетать их в одной компании: например, разработку вести по каскадной модели и ГОСТам, а для внедрения создавать scrum-команды. Главное, чтобы такие сочетания были нацелены на максимальную эффективность работы, скорость выполнения проекта и высокое качество разработки.

    Но всё же главное, чем вам стоит руководствоваться при выборе методологии, это накопленный опыт и здравый смысл. Моде здесь — не лучший советчик.

    Обещанное нравоучение про производительность


    В основе управления жизненным циклом разработки большинства программного обеспечения лежит системная инженерия в части инженерии производительности ПО (performance engineering), призванная обеспечивать подход и средства для создания жизнеспособных программ. Какая методология создания ПО ни была бы выбрана, инженерия производительности (PE) применяется хотя бы на одном из этапов. Вот как оценивают важность инженерии производительности различные специалисты в применении к некоторым аспектам разработки и методологиям:


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

    1. управление уровнем услуг (SLA) — установление соответствия ПО требованиям, мониторинг и анализ работы систем;

    2. управление инцидентами, проблемами — решение проблем, свзяанных с производительностью, перенастройка устройств, изменение конфигураций устройств, рефакторинг кода с целью повышения производительности;

    3. управление ёмкостью — перманентный мониторинг с целью установления соответствия ПО нефункциональным требованиям в динамике. Так, например, если в ходе анализа выясняется, что производительность системы упала в условиях возросшего количества пользователей или транзакций, принимается решение об изменении конфигурации оборудования или ПО с целью возврата к нормативным для требований показателям.

    Инженерия производительности с развитием научно-технического прогресса не теряет своей ценности, а напротив, выходит на передний план. Современные возможности создания GUI, использование баз данных со сложной архитектурой, работа с облачными технологиями бросают производительности вызов, на который должна отвечать именно PE, причём на всех этапах жизненного цикла продукта.
    Возьмём, к примеру, нашу систему Ruli24. В конфигурациях для среднего и крупного бизнеса (например, банков, промышленных предприятий, телекома) — это довольно сложное ПО. К тому же, наша система работает под управлением СУБД Oracle, мощной, но имеющей славу «медленной». Мы тщательно работаем над производительностью и архитектурой нашего ПО, стремясь обеспечить минимальное время отклика для текущей конфигурации. Нам это удаётся. И дело вовсе не в Oracle, дело в умении управлять архитектурой и постоянном рефакторинге кода.

    И ещё несколько методологий


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

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

    • DSDM (Dynamic Systems Development Method, метода разработки динамических систем) — методика разработки ПО, основанная на RAD (быстрой разработке приложений) и нацеленная на соблюдение бюджета и сроков сдачи проекта. Эта модель популярна благодаря своим преимуществам, в частности гибкости, демократичности, значительному взаимодействию внутри команды и с будущим пользователем, возможности итеративного похода и разделения компонентов на ключевые и второстепенные.

    • RUP (Rational Unified Process) — ещё одна методология итеративной разработки, в ходе которой работа над проектом строится из нескольких итераций по 2-6 недель, на выходе каждой из которых должен получаться промежуточный работоспособный продукт. Проект делится на четыре стадии: начальную с формированием видения проекта, оценкой рисков, выработкой требований и экономическим обоснованием; уточняющую с документированием требований и проектированием архитектуры; стадию построения, включающая разработку до релиза; заключительную стадию внедрения, обучения и сопровождения.

    • RAD (rapid application development, быстрая разработка приложений) — методология, направленная на быструю и удобную разработку программного обеспечения. Согласно этой методологии проект разрабатывается за 3-5 месяцев небольшой командой разработчиков, а заказчик вовлечён в процесс ещё до начала разработки и участвует во всех стадиях. Акцент в методологии делается на оперативные изменения по требованию заказчика для функциональных и нефункциональных требований. Методология широко используется во всех сферах разработки, но не оправдана при наличие точных требований и жёстко установленной функциональности. RAD-технология удобная для разработки (и доработки) корпоративного ПО, поскольку это тот случай, когда сроки сжаты, а требования к функционалу, GUI, производительности в ходе процесса разработки могут изменяться.

    • Cleanroom Software Engineering (методология «чистой комнаты») — интереснейшая методология разработки ПО с сертифицируемым уровнем надёжности. Нацелена на предупреждение сбоев, багов и проблем производлительносьи в процесе создания, а не на ликвидацию проблем после окончания работ по созданию программного обеспечения. Жёсткая методлогия, не нашедшая широкого применения в коммерческой сфере.

    • MSF (Microsoft Solutions Framework) — методология, разработанная на основе практического опыта Microsoft. Это скорее, даже целая система управления проектами разработки, состоящая из множества моделей и правил. Она сочетает в себе каскадную и спиральную модели разработки, универсальна, поскольку не включает в себя жёсткие процедуры. MSF ориентирована на вехи, учитывает изменения проектных требований, основана на коротких итеративных циклах всей системы разработки: дизайна, кода, документации. Методология охватывает все стадии разработки продукта, включая внедрение, в результате которого и формируется бизнес-ценность. MSF во многих крупных компаниях как для внешней (заказной) разработки, так и для разработки по техническим заданиям внутренних заказчиков.

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

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

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

    С кем мы будем рады сотрудничать?

    • С теми, кто будет вести проекты внедрения в регионах.
    • С интеграторами.
    • С теми, кто готов дорабатывать Ruli24 и зарабатывать на этом.
    • С агентами и дилерами-продажниками, тренерами и коучами.

    Ну и конечно, мы всегда открыты для встречных предложений сотрудничества. Всегда рады вашим письмам и звонкам!
    ООО «ИЛАДА»
    31.19
    Ruli24 — комплексная система автоматизации бизнеса
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 25

      0
      Мегамозг, не?
        0
        Хм, разве? Управление разработкой, agile — это всё же тема для менеджеров проектов и тимлидов. Пост очень даже в тему Хабра.
          +3
          Так вроде Мегамозг как раз для тем для менеджеров проектов и управления бизнесом. А впрочем я (да и не только я, видимо) совсем запутался уже что куда.
            +1
            Управление проектом, управление бизнесом и управление проектами разработки — это понятия, которые сильно отличаются по своей сути. Всё же управление разработкой — хаб Хабра, так что вроде всё логично.
        +4
        Зашел почитать про разработку ERP, CRM и ИТ инфраструктуры, а мне тут опять agile'ом мозг засирают.
          –1
          А что, agile не применим к разработке корпоративного софта? Или все методологии не применимы? По опыту вам скажу, ничего особенного в такой разработке нет, всё вполне по циклу: сбор требований, постоянная наработка функционала релиз за релизом, заморочки на том, чтобы GUI был всем понятен: от секретарши до гендира, интеграции с телефонией и 1С, выбор БД. С графовой БД под CRM не размахнёшься, поэтому выбор падает на стандартные реляционные: от Firebird до Oracle.

          А вот ИТ-инфраструктуру разрабатывать как таковую нельзя, поскольку она состоит из элементов, среди которых есть ПО разного типа, каждый из которых разрабатывался по-своему.
          +4
          Agile — это сокращение расходов на разработку за счет значительного понижения качества разрабатываемого продукта. Именно поэтому государственные, военные (и игровые вроде Blizzard) компании выбирают классический «водопад», чтобы получить на выходе более высокое качество продукта для длительной эксплуатации, а не наколенное недоделанное *овно, слепленное из недоразвитых «супер» идей бизнес менеджмента.
            +2
            А ещё под водопадом хорошо деньги прятать и сосать из инвестора/заказчика — это самая трудоёмкая и косная модель, благодать: накручивай и накручивай суммы. А вот agile ориентирован на исполнение бюджета. Насчёт качества продукта — это при любой модели можно г**** сотворить. Хотя отчасти быстрая разработка способствует размножению костылей, есть такое.
              +1
              Вы перепутали — это agile позволяет накручивать ценник за разработку, т.к. разрабатывается неизвестно даже что, поэтому манагеры говорят заказчику «мы тут в прошлой итерации попробовали и… не выстрелило, давайте в следующей итерации попробуем вот-так...»
              В случае водопада, создается качественная проектная документация, с подробным описанием функционала, архитекторы создают фреймворк для проекта, что позволяет довольно точно предсказать сроки разработки, т.к. все строится из заранее определенных стандартных блоков. Сроки в этом случае известны, ценник фиксированный в договоре.
                0
                Ага, знаем. К концу проекта, во время сдачи в эксплуатацию окажется, что ключевой пункт ТЗ не предусматривает один нюанс, и нужно очень дофига архитектуру переделывать. Но денег и времени на это нет, поэтому при помощи костылей и такой-то матери лепят имитацию нормальной работы, лишь бы тесты проходило. Исключений пока не встречал.

                Что касается документации, фреймворка и сроков — это все можно и в обычных итерациях предусмотреть. Итерация не обязана быть одним днем, это может быть и месяц, и полгода-год. Сколько угодно примеров, когда проект несколько раз менял даже не фреймворк, а полностью весь стек технологий из-за того, что в выбранном ранее обнаруживался тупик и проще все переписать, чем городить карточные домики из костылей.
              0
              Насчет близзардов не знаю, а государственные и военные обычно не создают что-то принципиально новое и непонятное, а заказывают "то же самое, тысячу штук". И тогда полное планирование процессов себя оправдывает.
              +2
              Agile — модная забава руководителей, для которых главное — ввязаться в проект. Априори предполагающая для исполнителя неоднократные переделки за те-же деньги и в те-же сроки.
                +3
                Как мне кажется, agile/scrum к российским реалиям совершенно не подходит.

                Во всех этих гибких методологиях заложена такая идея, что команда важнее продукта/результата. Т.е. если у вас есть команда которая может выполнять текущие задачи с некоторым успехом, то это намного важнее чем сможет ли она запилить продукт X. Т.к. сам продукт без команды мало что стоит. И это очень хорошо перекликается с ситуацией в кремниевой долине, где квалифицированный разработчик добавляет в среднем +1 млн. к капитализации компании при инвестиционной оценке ( http://blog.gust.com/10-rules-of-thumb-for-startup-investment-valuation/ )

                В РФ совершенно другая ситуация — найти хорошего инвестора и сформировать бюджет намного-много сложнее чем найти разработчиков. Поэтому неприкосновенность бюджета и работа "на результат" важнее ситуации в команде, и порой здравого смысла. Шаг вправо-влево от поставленной задачи приравнивается к предательству. Массовые увольнения практикуются как в мелких конторах, так и в очень крупных. Даже если формально и заявляется что разработка идет по agile, то как правило это такой "русский agile" где решение начальника закон, а разбор беклога сводится в итоге к ежедневной торжественной порке.

                Поэтому agile/scrum это не для РФ совершенно.
                  +2
                  найти хорошего инвестора и сформировать бюджет намного-много сложнее чем найти разработчиков

                  Ну если считать за разработчиков большую часть пользователей какого нить fl.ru, то да, найти их не проблема. Правильнее вашу мысль будет изложить (я считаю) так — в России нужно получить деньги на руки, а затем закрыть проект с помощью соплей и палок. В развитых странах такое не прокатит, ибо могут и засудить.
                    +2
                    Да, согласен, найти грамотного спеца в РФ намного сложнее чем в Калфорнии, но с инвестициями и финансированием все еще хуже.
                    +3
                    Методология тут совершенно ни при чем. Задача любой адекватной компании — это, в первую очередь, запилить продукт. Задача методологии сделать из рандомных людей команду с +- предсказуемой производительностью. Складываем второе и первое, и все счастливы.
                    Вы же говорите о низкой культуре управленческих кадров. Но это проблема не России, а конкретных людей и это везде так, поэтому многие и проваливаются безотносительно к географии и бюджетам.
                      +2
                      Мне кажется в РФ с культурой управления все довольно-таки хорошо. Проблема в том, что макроэкономическая реальность накладывает свои ограничения на пути развития бизнеса. И каким бы не было руководство демократичным на словах — на деле это мало отражается.

                      Вы ниже упомянули Грефа, про agile. Я тоже слышал это выступление, абсолютно согласен в этой части, что и организация должна перейти на Agile. Но структура организации обычно повторяет структуру финансовых потоков, тогда и финансовые потоки должны быть более горизонтальными и гибкими. Но это определенно не про страну в которой ставка рефинансирования 11% и за всю историю не опускалась ниже 8%.
                        +1
                        Не вижу связи, честно говоря. Наоборот, с той волатильностью, которая есть в экономике, я не представляю, как можно работать по-другому, чем не в Agile. Если у Вас есть такой опыт — расскажите!

                        с культурой управления все довольно-таки хорошо

                        Хм. Для меня отсутствие внятного планирования и оценки рисков, ужасные коммуникативные навыки, перманентный стресс, неспособность выстроить климат внутри команды, нетерпимость к ошибкам — это все плохая культура управления. А что для вас?
                          +2
                          Не вижу связи, честно говоря. Наоборот, с той волатильностью, которая есть в экономике, я не представляю, как можно работать по-другому, чем не в Agile. Если у Вас есть такой опыт — расскажите!

                          Допустим у вас есть agile-команда, которая работает на российского заказчика. В какой-то момент, заказчик движимый своими какими-то внутренними установками приходит и говорит — все, меня забодал ваш agile, теперь работаем как я скажу. В развитой экономике вы можете послать такого заказчика и покрыть расходы за счет кредитных средств (т.к. кредиты довольно дешевы). В РФ как правило, команды соглашаются на условия заказчика, т.к. найти какие-то средства или другого заказчика очень трудно.

                          Хм. Для меня отсутствие внятного планирования и оценки рисков, ужасные коммуникативные навыки, перманентный стресс, неспособность выстроить климат внутри команды, нетерпимость к ошибкам — это все плохая культура управления. А что для вас?

                          Я имел ввиду, что интеллектуальные и личные качества у российских тим лидов и управленцев в IT довольно хорошие. Но по сути они ни на что не влияют, т.к. все решения принимаются как правило теми кто ближе к финансам.
                          Конечно это тоже можно отнести к проблемам культуры управления, но скорее это все-таки проблема государства, института собственности и макроэкономических показателей. Т.к. это все приводит к тому, что собственники стараются владеть и управлять активами единолично. В итоге agile у нас приживается плохо.
                    +1
                    В этой методологии Agile интересен подход оценки выполненных работ в абстрактных единицах, а не в человеко-часах. У программистов есть определенные нюансы: программный код, обеспечивающий одну и туже функциональность может отличаться в размерах и человеко-часах в десятки, а то и сотни раз.
                      +2
                      Все-таки SCRUM в основном используется в проектах, над которыми работают небольшие команды из специалистов различного профиля как показано на картинке.

                      Картинка
                      image
                        +1
                        Вы, кстати, Грефа не услышали. Его основной посыл был в том, что вся организация, а не только ИТ, должна перейти на Agile.
                        Если уж вы стали писать про себя — сколько деплойментов в день вы делаете?
                          +1
                          Высказывания Германа Оскаровича на эту тему как-то странно интерпретируются, имхо.

                          Во-первых, основная мысль, которую он хотел донести до слушателей, заключалась в том, что в современных реалиях все большую роль в финансовой сфере начинают играть не банки, а ИТ-компании (такие как Google, Apple, Amazon и т.д.), которые залезают на этот рынок (Google Wallet, Apple Pay, Amazon Payments и т.д.), которым банки, и, в частности, Сбербанк, в ближайшей перспективе может начать уступать свои позиции, ЕСЛИ не сможет также оперативно предлагать новые продукты, модифицировать существующие продукты, исправлять неточности/ошибки и т.д.
                          Именно для этих целей Сбербанку (да и другим банкам) требуется новая парадигма управления изменениями, которая позволит возглавляемой им организации в обозримом будущем оставаться конкурентоспособной и прибыльной.

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

                          В-третьих, принципы управления компанией-разработчиком, имхо, очень сильно зависят от той категории клиентов, на которых она ориентирована.
                          Реалии, в которых существует Сбертех, автоматизирующий Сбербанк (имеется ввиду legacy, масштаб организации и все, что с этим связано), приводят к результату, который озвучил Герман Оскарович, т.е. к тому, что изменения в ИТ-системах вносятся достаточно неторопливо, т.к. производятся максимально осторожно, после многократного тестирования и проверок.
                          Увы, по другому нельзя, т.к. цена ошибки очень высока.
                          Вспомните хотя бы про >100 млн. карт, обслуживаемых Сбером, самую большую сеть отделений, банкоматов и пр.

                          Однако, учитывая кадровый состав Сбертеха :), я уверен, что этим людям вполне под силу выработать новые решения, которые позволят Сберу на равных конкурировать с Амазоном, Гуглом и т.д.
                            0
                            Есть мнение, что будущее в финансовой и банковской сфере за ИТ компаниями, которые будут иметь банковские лицензии. Вероятно, поэтому Греф говорит о Сбербанке, как о самой крупной ИТ компании РФ.
                            Я соглашусь с вашим мнением о том, что ускорение обработки данных вряд ли способствует ускорению внесения изменений в процессы Сбера.

                            Здесь нужна другая система управления процессами, включая процессы исследования новых направлений оказания банковских услуг, и процессы управления проектами новых решений, и бизнес процессы создания, тестирования и установки версий действующего ПО, и процессы технической поддержки пользователей, и процессы управления взаимоотношениями с клиентами. Возможно, им могло бы быть полезно наше решение Рули24 Управление процессами
                            0
                            За 2015г было создано около 200 версий различных модулей ПО и сделано более 2000 установок на наши сервера и сервера клиентов. Всего сделано боле 10 000 изменений.

                          Only users with full accounts can post comments. Log in, please.