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

На Гайдаровском форуме Герман Греф заявил, что Сбербанк будет переходить на новые информационные технологии, выбрав в качестве основного партнёра российско-американскую компанию с численностью 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. Он может возникнуть в трёх основных случаях.

Заказчик перегибает палку, меняет требования без веских на то оснований и команда превращается в машину по непрерывному, авральному рефакторингу. Менеджер всего проекта (scrum-мастер) обязан пообщаться со стороной клиента и разъяснить, что требования должны быть обоснованными и соответствующими целям бизнеса. Чехарда в разработке и постоянная смена направлений развития продукта к хорошему не приводит.
Команда не может самоорганизоваться и превращает agile в распущенность и пустую болтовню на совещаниях. Действительно, до 30% времени спринта уходит на собрания и совещания (перед спринтом 4–8-часовое собрание, после и каждый день не более 15 минут). Нужно донести до команды, что эти совещания — важная часть работы над проектом и их задача не обмен сплетнями и шутками, а собранное обсуждение проблем, задач и времени проекта. В конце концов, на кону удовлетворённость клиентов, доход компании и персональный доход каждого сотрудника.
Снижение качества продукта за счёт небрежного отношения к технологиям разработки и особенностям ИТ-инфраструктуры. Действительно, бывает так, что команда, увлекшись юзабилити или дизайном, напрочь забывает о производительности, рефакторинге и тестировании на разных сборках. Здесь на помощь приходит менеджмент производительности, который также должен стать бизнес-процессом. О нём я расскажу чуть ниже.

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 устанавливает требования к системам и изучает производительность на различных конфигурациях (нагрузка, вид операционной системы, взаимодействие с различными типами устройств и т.д.), лучшие из которых будут использованы в продакшене. После внедрения ПО инженерия производительности отвечает за три основные области:

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

Инженерия производительности с развитием научно-технического прогресса не теряет своей ценности, а напротив, выходит на передний план. Современные возможности создания 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 и зарабатывать на этом.

С агентами и дилерами-продажниками, тренерами и коучами.

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