что такое коробочные решения
Как компании получить больше выгоды от коробочного решения и разработки ПО на заказ
На протяжении своей деятельности в IT-сфере, часто встречалась следующая ситуация — это когда у компании появилась потребность автоматизировать определенный бизнес-процесс или направление с помощью нового ПО.
При этом необходимо было выбрать вариант: использовать готовое решение (коробочное) или разрабатывать его на заказ у аутсорсинговой IT-компании.
Что же, давайте разберем эту ситуацию. В этой статье я опишу свое видение, которое основано на опыте участия в разработке и использованию различных IT-систем и программного обеспечения.
Готов к запуску или коробочное решение
Возможно вы слышали такие выражения как:
Коробка, коробка, коробка. Что имеется ввиду?
Коробочный продукт — так называют IT-систему или программное обеспечение (ПО), в котором собраны часто используемые функции для решения типовых задач и процессов. Они присутствуют в каждой компании конкретной отрасли или в целом.
К примеру, CRM система для отслеживания воронки продаж, сбор базы клиентов и работы с ней. Она может использоваться в каждой компании, вне зависимости от отрасли.
Данный подход нацелен на массовое распространение готового программного обеспечения для компании вендора, как на локальном рынке, так и на зарубежном. 
Здесь я обозначил 5 пунктов, на которые чаще всего обращают внимание клиенты и пользователи при выборе готового ПО.
По моим наблюдениям и опыту использования различных коробочных решений — большим минусом является то, что готовое ПО не может полностью соответствовать требованиям вашего бизнеса. Так как оно разрабатывается для большого количества компаний.
Из-за этого часть функционала который включен по умолчанию, может даже не использоваться вашими сотрудниками, либо плохо реализован или вообще отсутствует.
Подведем итог по коробочному решению
Если вашему бизнесу необходимо решать типовые задачи, провести быстрое внедрение и обучения сотрудников, то данный подход по использованию «коробочного» решения является правильным. Даже несмотря на размер вашей компании и прочие ограничения, которые следует при использовании готового ПО.
Заказная разработка — лучше коробочного решения, когда.
И вот компания достигла момента, когда требуется использовать собственное программное обеспечение, так как коробочное ПО уже не справляется с новыми процессами и задачами.
Плюсы заказной разработки
Несмотря на все сопутствующие минусы, которые только могут быть при заказной разработке, я могу обозначить из них 2 основных. Они чаще всего встречаются в практике — это стоимость и сроки. Так как необходимо проделать большой объем работы по подготовке и самой разработке нового ПО.
Что же использовать в конечном счете?
Я считаю, что лучшее решение — это когда вы можете использовать оба подхода для решения поставленных перед вашей компанией целей.
Для решения типовых задач — используйте коробочное ПО, а для нестандартных и узкоспециализированных задач — разработку на заказ.
При этом необходимо позаботиться о том, чтобы эти два подхода дополняли друг друга и образовывали единую систему, а не просто существовали друг от друга, усложняя работу сотрудниками и притормаживая деятельность компании.
Облако или коробка: что выбрать?
Немного о системной интеграции. Игорь Комарницкий из «РемонтОнлайн» даёт ликбез о коробочном и облачном ПО.
Итак, вы запускаете новый бизнес или решили автоматизировать процессы в существующем. Стоит непростой вопрос: как организовать экосистему. Заказать коробочный сервис или воспользоваться готовым облачным решением? Давайте разберёмся.
Сразу разложим по полочкам. Коробочное решение или standalone — это программное обеспечение, заказанное у аутсорсинговой компании или выбранное из готовых предложений на рынке, но поддержка и дальнейшее развитие ведётся исключительно штатными разработчиками заказчика/покупателя ПО.
Облачные решение (SaaS — Software as a Service — программное обеспечение как услуга) — программное обеспечение, разработка и поддержка которого осуществляется поставщиком, а заказчик получает онлайн-доступ к готовому ПО.
Теперь о каждом из решений подробнее.
Плюсы и минусы коробочного решения
«В коробке» заказчик приобретает базовый пул программ, не заточенный под нужды его компании, но имеющий возможности для доработки под нужные требования. Это своего рода конструктор с набором стандартных возможностей, которые нужно приспособить для частного случая.
Инновационные цифровые решения для фарммаркетинга:
Плюсы и возможности
Коробочные сервисы покупаются единоразово и, как правило, без каких-либо ежемесячных выплат.
Считается, что коробочное решение надёжнее облачного, так как данные хранятся на сервере компании, а разработка и поддержка ведется штатными разработчиками.
Заказчик сам осуществляет контроль и берёт ответственность за безопасность данных.
Для использования коробочного ПО не нужен интернет, так как программа устанавливается на компьютер.
Минусы и опасения
Первоначально нужно будет вложить солидную сумму денег без гарантий, что она окупится.
Нужна техническая поддержка (отдел разработки) для установки и разворачивания программы. Получается, что при покупке коробочного решения вам будет необходим как минимум небольшой штат из разработчиков, способных поддерживать и развивать ПО.
Возможны конфликты с уже существующими программами.
Обязательная установка программы на компьютере.
Кому подходит коробочное решение
Продуктовые компании с долгосрочной перспективой развития ПО.
Крупные компании, у которых есть время и бюджет на разработку.
Государственные структуры, а также компании, которые «одержимы» идеей безопасного хранения данных.
Плюсы и минусы облачного сервиса
Плюсы и возможности
Заказчик не платит за разработку ПО, платит за аренду.
Также не нужно приобретать дополнительное оборудование: покупать серверы и содержать отдел разработки.
Доступ к программе через мобильное или компьютерное устройство.
Для облачного ПО нет разницы, какая операционная система стоит у вас. Пользователи Mac, Windows или Unix могут без проблем обмениваться данными между собой.
В любое время можно зайти в программу: доступ 24 часа в сутки, 365 дней в году.
Техподдержка и обновления осуществляется разработчиками со стороны подрядчика, а значит, можно вычеркнуть солидную затратную часть на штатных ИТ-специалистов.
Нет ограничений по объёму памяти.
«Главный миф об облачных решениях — ненадёжное хранение данных. На самом деле, данные пользователей надёжно хранятся на серверах подрядчиков, а информация передается по зашифрованному протоколу. В случае форс-мажора данные восстанавливаются с помощью резервного копирования. Если отправить данные через облачное решение, то они сохранятся и автоматически будут отправлены на запасные серверы в разные точки мира. И даже если программа не обновляется в облаке, клиент всё равно имеет к ней доступ».
Минусы и опасения
Ежемесячная оплата аренды из расчета количества пользователей и используемых услуг.
Доступ к программе только через интернет.
Контроль хранения данных осуществляет подрядчик.
Кому подходит облачное решение
Практически для любого бизнеса уже существует готовое облачное решение. Например, для хранения, редактирования и передачи данных есть «Google Диск», для ведения бухгалтерского учёта — «1С-онлайн».
Средняя стоимость
Мы сравнили цены на коробочные и облачные сервисы в странах СНГ и попробовали вывести среднюю стоимость. Проверяли решения для ведения базы клиентов, финансового учёта.
Сравнивали коробочные решения с нашим «РемонтОнлайн».
* Цены указаны для комплексных решений (Нескольких слоев автоматизации)
**Тут указаны настоящие цены за облачный сервис компании «РемонтОнлайн».
Вывод
Нельзя однозначно сказать, что одно решение лучше другого. Тут каждый бизнес решает сам, отталкиваясь от задач и бюджета. Но зная плюсы и минусы, сделать выбор проще.
Бизнес хочет коробочные решения на всё. Кого-то волнует закон Яровой?
Мы провели опрос наших пользователей на тему “Нужна ли коробочная версия системы управления проектами?”. Для нас точный ответ на этот вопрос имеет большое значение. Определяет путь развития системы и приоритеты по новым функциям.
В опросе приняло участие 155 компаний использующих облачную версию или просто тех, кто зарегистрировался познакомиться с системой. Было всего три вопроса, в каждом по три варианта ответа.
Под катом графики с результатами и наши выводы.
Выборка
Выборка не слишком большая (155 респондентов), пользователи не очень любят получать письма и тем более за что-то голосовать. Единственной мотивацией к участию было обещание опубликовать результаты.
Количество опрашиваемых по каждому вопросу получилось в 50 раз больше количества вариантов ответов. Случайная погрешность распределения по ответам будет не большой —
несколько процентов и зависит от распределения по ответам.
К существенным неточностям эксперимента можно отнести вероятностность выборки — голосовали только те, кто хотел, а не случайные пользователи из генеральной выборки. И, конечно, саму выборку — в нашей базе есть перекос в малый бизнес.
Все эти факторы стоит учитывать и можно делать выводы по результатам опроса.
Нужно ли коробочное решение для управления проектами или облачное тоже подойдет?
32% респондентов принципиально готовы работать только с коробочными решениям для общения и работы с задачами. Если учесть, что среди наших респондентов есть перекос в малый бизнес, то 32% это минимальная доля рынка не рассматривающая SaaS вообще.
Несколько лет назад такой ситуации не было. Мы тогда работали над другим b2b проектом, но запросы на коробку были единичны, их просто не рассматривали всерьез. Сейчас, выпустив коробочную версию, мы закрыли самый популярный коммерческий запрос.
Какова главная причина необходимости коробочного решения?
Сильный перекос в безопасность и хранение данных у себя — более 60%. И это по малому бизнесу! Когда напрямую общаешься с крупными компаниями, там безопасность и коробочное решение это всегда первый или второй вопрос. (конкурирует с вопросом: «Как получить отчет о том, чем занималась команда»)
За последние 3 года коробочные решения стали актуальней? Закон Яровой как-то влияет?
Сам по себе закон Яровой никого сильно не волнует. Нет чего-то одного конкретного ставящего безопасность так высоко. Это всегда совокупность многих факторов, причем изменения в этих факторах пользователи действительно не прослеживают. Характерный диалог у нас с клиентом выглядит так:
— Нам нужно коробочное решение.
— А почему именно коробочное? давайте начнем с облачного, так быстрее запуститься
— Нет, сейчас руководство согласится только, если будет установлено на наши сервера
— А что поменялось, ведь пока вы пользуетесь бесплатным облачным Trello?
— Да и нас это не устраивает. Особенно ничего не поменялось, но теперь политика перехода только на безопасные решения.
Выводы из опроса и общения с компаниями:
P.S. Опрос: Agile в России 2017
Мы в YouGile проводим большой опрос о гибкой методологии в России. Тут нужно на порядок больше респондентов, чем в опросе выше. Пока приняло участие чуть больше 100. Самый популярный ответ на вопрос: «Используется ли Agile в вашей компании?»
«Да, но совсем немного» — 54,5% респондентов.
Результаты обязательно будут опубликованы на Хабрахабр.
Коробочное или заказное решение. Что выбрать?
Готовое, но ограниченное, или разработка с индивидуальными характеристиками
По мере роста каждая компания рано или поздно задумывается об автоматизации внутренних бизнес-процессов. Это могут быть процессы, связанные с договорной или документационной деятельностью, процессы маркетинга и продаж или даже автоматизация производственных процессов.
И первый вопрос, который встает перед компанией – выбрать коробочное решение или решение под заказ?
Оба варианта имеют свои достоинства и недостатки и зависят от множества внутренних и внешних факторов. В данной статье мы попытаемся более подробно осветить этот вопрос и дать советы по выбору решения.
Коробочное решение
Такие решения зачастую называют просто «коробкой». Это уже готовый к использованию продукт.
Самый очевидный плюс коробочного решения – это скорость внедрения. Коробочные решения уже имеют набор функций и автоматизированных бизнес-процессов, которые можно использовать сразу после установки. Установка и настройка также не занимает много времени и после добавления пользователей и заполнения справочников решение готово к использованию. При этом установка может быть выполнена собственными силами IT-специалистов компании, а иногда и рядовыми сотрудниками при наличии должной квалификации.
Еще одним плюсом является цена на такие решения. Как правило, они значительно дешевле, чем разработка решения на заказ. В некоторых случаях цена может отличаться в несколько раз. Кроме того, стоимость необходимых модулей и функций можно посчитать заранее, без обследования бизнес-процессов заказчика.
К основным минусам коробочных решений можно отнести ограниченность функционала. Набор функций, бизнес-процессов и их реализация в решении заранее настроены разработчиком, чтобы охватить как можно больше компаний. Поэтому, если интерфейс или выполнение каких-то действий не удобны для пользователей, то глобально их поменять не получится и придется пользоваться тем, что есть. Это же касается бизнес-процессов и маршрутов движения документов. Они, как правило, настроены определенным образом и неподготовленные пользователи могут испытывать сложности с их изменением.
В большинстве своем коробочные решения не рассчитаны на то, чтобы их развивать. Поэтому доработать новый функционал получится не всегда. Обычно есть ограниченное количество настроек, которые можно менять, а глобальные изменения или новые функции появляются в следующих версиях системы.
Еще один минус таких решений – это отсутствие индивидуальной технической поддержки. Если в результате использования системы у вас появится какая-то системная ошибка, то разработчик решения скорее всего даст вам патч для ее исправления. Во всех остальных случаях вам придется решать проблемы самостоятельно, ища информацию и задавая вопросы на форумах.
Заказное решение
Разработка решения на заказ в отличие от коробки начинается с анализа бизнес-процессов, задач и проблем клиента. Аналитики поставщика решения беседуют с ключевыми сотрудниками заказчика, исследуют существующие бизнес-процессы, выявляют существующие проблемы, знакомятся с регламентами компании. После обследования и изучения потребностей составляется техническое задание. Следующий этап – разработка и внедрение решения. После идет тестирование системы пользователями заказчика и его доработка в случае проблем и замечаний.
В большинстве случаев заказная разработка ведется уже на основе какого-то базового решения с определённым набором функций и возможностей. Это базовое решение дорабатывается под нужды и потребности заказчика. Такой подход позволяет сделать систему максимально удобной и подходящей к конкретной организации. В этом случае учитываются все особенности внутренних процессов в компании. При изменениях в компании, решение может быть доработано или переработано в индивидуальном порядке, что нельзя сделать с коробочным.
Еще одним плюсом является индивидуальная техническая поддержка. Вы можете договориться с поставщиком об условиях поддержки, которые будут вам нужны.
К минусам заказных решений стоит отнести цену и сроки внедрения. Обычно они составляют от 3-4 месяцев и более.
Выбор за вами
В платформе Citeck ECOS мы постарались учесть особенности «коробки» и заказного решения. Есть версии Standard и Enterprise. Они предназначены как для средних проектов до 100 пользователей, так и для крупных. Например, в российском подразделении Unilever систему использует более 7000 сотрудников и автоматизировано 25 бизнес-процессов.
С помощью Citeck ECOS можно организовать локальную систему на базе одного модуля «Договоров» или развернуть экосистему на все предприятие. В расширенной версии настраивается работа внутри отделов, с филиалами и контрагентами, интегрируются корпоративные ERP и операторы ЭДО в единую платформу. Система обладает очень большой гибкостью в настройке.
Чтобы реализовать кастомизированный вариант мы обследуем бизнес-процессы заказчика, изучаем регламенты, беседуем с сотрудниками. После тщательно обследования Citeck ECOS настраивается в соответствии с потребностями и ожиданиями заказчика. При необходимости можем полностью изменить бизнес-процессы, логику действий и интерфейс системы.
Citeck ECOS — это Open Source Software, базовым решением для которой еще на стадии зарождения стала международная ECM-система Alfresco. Сегодня, это уже полноценное российская разработка, которая адаптирована под законодательные аспекты страны и бизнес-практику.
Эффективность достигается за счет принципа адаптивного управления кейсами (ACM) и интеграции его с BPM-движком. Такой подход расширяет возможности стандартных BPM и ECM систем. Конструирование типовых процессов проходит в 5-6 кликов, а при необходимости их изменить в большинстве случаев не требуется привлечение программистов — используется так называемый low-code.
У нас уже есть опыт внедрения в самых различных сферах экономики: гос. структуры, страхование, логистика, банки, FMСG и т.д.
Узнать больше о платформе Citeck ECOS можно на странице продукта или функциональных решений.
А не спроектировать ли нам систему для управления производством ИТ продуктов. Часть 1. Анализ коробочных решений
I Вступление
Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.
За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воочую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.
Вообще тема автоматизации управления процессами разработки и внедрения ИТ продуктов очень интересна и амбициозна, особенно для аналитиков и архитекторов. Ведь они жаждут получить в «одном флаконе», сквозную трансляцию всех процессов, начиная еще со сбора требований, далее к проектированию и моделированию, и уже через них протоптать дорожку непосредственно к разработке. И ведь мало им своего собственного хотения, так они еще подзадоривают менеджеров проектов и продуктов, открывающимися при таком подходе горизонтам к почти безграничным возможностям оценки и планирования проектных работ.
В данной публикации я хочу еще раз подытожить свой опыт в этом вопросе и спроектировать элементы системы, как я ее вижу. Формат публикации не позволяет привести полное ТЗ, поэтому я постараюсь описать наиболее важные с моей точки зрения детали, а так же сами рассуждения по выбору тех, или иных решений. Кому интересно прошу со мной…
II Анализ рынка решений
Исследовать — значит видеть то, что видели все, и думать так, как не думал никто
Альберт Сент-Дьерди
Наверное одна из самых популярных систем такого класса — Jira, которая иногда заявляется как система управления проектом. Хотя на мой взгляд, она далеко не дотягивает до такого уровня. Может если только, как часть системы, совместно с Confluence, MSProject и прочими инструментами. Гораздо гармоничнее она вписывается в классификацию — система для организации взаимодействия с пользователями. Еще подобные системы, из тех что на слуху, с разной глубиной предоставляемых функций: Redmine, MeisterTask, Zoho, TaskWorld, MantisBT.
А еще есть системы по управлению репозиториями, дополненные возможностями управлять задачами и вести простенькую базу знаний. Например, GitLab. Есть и другие ниши из которых могут пробиваться подобные решения.
1. Стандартизация функций систем, представленных на рынке
Агрегируя потенциал вышеупомянутых средств, можно выделить следующие востребованные функции:
2. Недостатки существующих систем
По факту большинство систем такого рода неплохо поддаются настраиванию под конкретные нужды команд, но все равно есть множество спорных нюансов, о которых упомяну вкратце:
На самом деле, в реальном проекте не так уж много людей, которым взаправду необходима сквозная трассировка информации от потребностей пользователей, до реализованных функций в конкретной версии продукта. Чаще всего, таковыми лицами выступают архитекторы и системные аналитики, которые впрочем не всегда готовы активно биться за свои интересы в системе управления проектами. Ведь это не только накладно по времени, но еще и требует жертв, в виде взваливания на себя дополнительной ответственности и потерянных безвозвратно нервов.
Хотя наверное, если кто-то такую систему организовал бы, вся команда была бы в выигрыше. Ведь это позволяло бы обеспечить детализацию всей системы, на подсистемы, их на модули и контуры, их на сервисы и функции и т.д. А те, в свою очередь связывать не только с элементами на формах пользователя, но и с конкретными версиями продукта, веток кода, в которых эти функции реализованы и т.п. При всем при этом, детализацию хорошо бы визуализировать в виде схем (архитектуры решения), с переходами, погружающими вглубь по уровням конструкции.
Для описанного в вики-системе требования, в трекере появляется набор задач с разными типами: на оценку, на проектирование, на реализацию, на тестирование, на передачу заказчику и т.п. В каждой из них тоже есть небольшое описание – экскурс в проблему, и помимо ссылки на требование в вики, ссылки на смежные задачи, Вся гирлянда, в лучшем случае, оформлена, как главная задача и подзадачи (уровень вложенности ограничен). В самих задачах могут быть свои комментарии, со ссылками на прочие комментарии и т.п.
В процессе выполнения могут меняться исполнители, ожидаемые версии продукта, приоритеты исполнения, метки, компоненты и прочее, прочее, прочее… Весь этот клубок задач необходимо как-то синхронизировать, поддерживая в актуальном состоянии и обеспечивая непротиворечивость данных. Глядя на подобную пеструю картинку многообразия, чувствуется большая, большая натяжка. Пожалуй слово «большая» уместно употребить и в третий раз.
Все вышеперечисленное и еще некоторые другие моменты, вскрывают червоточины во вроде бы красивых и “сочных” решениях.
3. Вызовы при создании системы поддержки производства информационных систем
На практике можно наблюдать две крайности в построении подобных продуктов:
Второй способ чаще применяется в больших долгосрочных проектах, которые неизбежно связаны со сложными, измененяемыми в ходе реализации требованиями, или при создании линейки тиражируемых продуктов, которые необходимо будет кастомизировать. Трудности появляются еще в процессе оформления требований в системе, возрастают при их изменениях в разных проектах, версиях продуктах и т.п. Трудности, связанные со сложностью восприятия контекста всего проекта, его отдельных частей и их взаимодействия, углубляются и при попытках подключить к проекту новых исполнителей, и при необходимости развития продукта. Такой подход требует привлечение высококвалифицированных специалистов, дополнительного обучения, значительных временных затрат Цена поддержки такой системы может быть высока.
Вообще в больших, сложных проектах есть узкое место – контекст проекта. Детальное описание того, что и как необходимо реализовать. Иногда, это огромный массив информации, который лишь как-то структурирован. Хуже, когда эта информация размазана по разнородным артефактам, или сознанию заинтересованных лиц. То есть, выставляя новое задание разработчику, необходимо понимать, что ему придется потратить дополнительное времени на ознакомление с контекстом решаемой задачи и текущей реализацией взаимодействующих с его решением компонентов.
Вот как раз эти проблемы и должен помочь эффективно решить рассматриваемый нами продукт, поддерживающий процесс разработки и внедрения информационной системы.
III Проектирование базовой структуры системы
— Я создам идеальное общество, создам такой мир, в котором будут жить только ответственные и добрые люди!
— И в этом идеальном мире ты окажешься единственным злодеем…
(Тетрадь смерти)
Давайте начнем скруглять озвученные в предыдущей части угловатости.
По идее анализ может начинаться с рассмотрения процессов, которые мы будем автоматизировать. Но если их описание затолкать в данную статью, она получится чересчур загроможденной и будет тяжело восприниматься аудиторией. Тем более, что я уже проводил подобный анализ и сейчас просто сошлюсь на свою публикацию «Производство информационных систем».
1. Деление решаемых проблем по типам
Чтобы не лепить в кучу несовместимое, тщательно отделим зерна от плевел. Рассматривая весь процесс создания информационной системы: «Проектирование – Реализация – Внедрение», удобно поделить проблемы на 3 основные типа, связанные с:
Модель данных может быть организована, как показано на рис.1.
Рисунок 1. – Модель классификации задач
Все типы задач целесообразно наследовать от одного класса, на который можно навесить глобальные атрибуты задания, включая и «отчет» о его выполнении.
На основании вышесказанного давайте воспроизведем всю картину процесса работы с системой управления разработкой информационных систем целиком.
Итак, сначала возникают требования пользователя. Являются они не сами по себе, а в ходе выполнения выставленных для этого исполнителям (аналитической группе) задач. В результате выполнения этого же пула работ, формируются Спецификации на реализацию решения в коде. С сим к процессу могут подключиться ведущие специалисты из цеха разработки.
Далее, по готовым спецификациям выстраивается новый пул задач исполнителям (программистам), уже в ходе решения которых, могут потребоваться сборки готового (или не очень) продукта.
Следующим шагом, используя параметры и характеристики сборки, а так же мест их дислокации, в службу поддержки и внедрения вливается своя свита задач, надлежащее решение которых и приводит к полноценному использованию информационной системы заказчиком.
Таким образом, отталкиваясь ли от задач, или от самих основных объектов: Требование, Спецификация, Сборка, мы может проследить весь путь от проблемы до конкретного решения в продукте, а также все активности продвигающие это решение по непростому, тернистому пути.
Сама же задача теперь отодвинута в системе с центральной позиции вглубь, поскольку акцент мы вынесли на объекты, в рамках которых эта задача и выполняется, а ей же самой остается лишь роль назначения исполнителя и уточнения самого действия. Ну и отчет конечно будет формироваться по задаче. Таким образом в заголовке задачи теперь должны превалировать глаголы. В моей практике встречаются менеджеры, которые создавая задачю (task) не используют ни одного глагола, и каждый раз возникает вопрос к автору: «А что же всё-таки надо сделать, где пресловутое побуждение к действию?».
Задача в ходе своего жизненного цикла проходит разные стадии, которые проецируются в системе статусом. Например так, как представлено на рис.2.
Рисунок 2. – Модель перехода состояний задания
Возможно такой подход и заставит тратить чуть больше времени в проекте, но это только на начальном этапе. Эти затраты будут с лихвой отыграны за счет снижения хаоса в системе и более строгой организации самого техпроцесса.
В следующей части рассмотрим детально каждый пул работ по-отдельности «Часть 2».