Системы документооборота и автоматизации бизнес-процессов призваны наводить порядок в работе компании. Они систематизируют документационное обеспечение компании и прокладывают четкие, прямые, неизменные маршруты, по которым движется работа над документами. Таким образом, система документооборота упорядочивает хаос и анархию в повседневных делах фирмы, задает ей определенный темп и график деятельности.Но для того чтобы создать инструмент, способный что-то систематизировать и упорядочивать, нужно для начала самим научиться систематизировать и упорядочивать свои дела. Для нас главное дело — разработка системы документооборота ТЕЗИС. Поэтому неудивительно, что работа над каждым новым релизом системы тоже движется по четкому маршруту — как работа над любым документом в нашей СЭД.
В этой статье мы хотим ненадолго пустить читателя на внутреннюю кухню разработки системы документооборота. Мы расскажем об этапах подготовки к релизу СЭД ТЕЗИС и покажем, как выстроена работа над новыми версиями. Возможно, наш организационный опыт окажется кому-то полезным.
Этапы разработки новой версии СЭД ТЕЗИС
Новая версия СЭД ТЕЗИС выходит раз в год. День рождения каждого нового релиза мы отмечаем осенью, как правило, в конце сентября-начале октября. Однако подготовка к выпуску новой версии системы начинается еще глубокой зимой, когда составляется план-график работы над релизом.
Каждый год для всего проекта ТЕЗИС формируется общедоступный документ — план-график релиза, в котором подробно расписываются этапы работы над новой версией системы. Их у нас четыре:
- Подготовка к разработке;
- Разработка новых возможностей системы;
- Подготовка к выпуску нового релиза;
- Выпуск релиза.
Каждый этап включает в себя многочисленные промежуточные этапы, которые также прописываются в графике. Кроме того, в нем прописываются сроки, к которым должен быть завершен тот или иной промежуточный этап.
Как правило, подготовка к разработке идет в марте-апреле; на разработку отводится время с мая по август; подготовка к выпуску идет в августе- сентябре, и в октябре выходит релиз, после чего до ноября новая версия устанавливается у клиентов. К началу ноября также выходят свежие версии ТЕЗИС: Портала, модуля «Единый холдинг», Мобильной версии системы и других веток системы ТЕЗИС.
Подготовка к разработке СЭД: решето для идей
До начала марта вырабатывается общая концепция развития продукта на год релиза, проводится предварительный сбор идей, предложений и замечаний.
1 марта создается документ для сбора предложений по новому релизу и до середины марта сгенерированные за зиму идеи для разработки системы электронного документооборота вносятся в него. В документ вносят предложения следующие участники:
- Руководитель направления «Электронный документооборот».
- Менеджеры отдельных проектов внедрения ТЕЗИС. Они привносят в документ идеи и замечания, родившиеся в ходе реальной работы на проектах уже существующих клиентов.
- Директор по продажам. Он консолидирует идеи от всех сотрудников отдела продаж, появившиеся на основе требований клиентов, с которыми велись переговоры о внедрении системы.
- Руководитель отдела технической поддержки. Вносит в документ идеи, сформированные его отделом на основе пожеланий клиентов.
- Руководитель отдела тестирования. Вносит в документ замеченные ошибки системы, которые возникли в предыдущей версии.
- Руководитель отдела разработки. Вносит в документ предложения от разработчиков.
- Руководитель отдела маркетинга. Вносит в документ идеи, возникшие на основе актуальных трендов рынка СЭД, идеи по дизайну, usability интерфейса.
- Бизнес-аналитик. Вносит в документ идеи, возникшие на основе накопившейся за год информации о новых технологических возможностях, об изменениях у конкурентов, изменениях в законодательстве, касающихся требований к СЭД.
После того, как документ заполнен, начинается отбор идей. Предложения проходят через «решето» — два экспертных совета, один из которых проходит в середине марта, а второй — в середине апреля.
В экспертный совет входят руководитель направления «Электронный документооборот», директор по продажам, начальник отдела техподдержки, начальник отдела тестирования, руководитель отдела разработки, бизнес-аналитик и руководитель отдела маркетинга.
На первом экспертном совете формируется предварительный пул доработок. Экспертный совет обсуждает каждый пункт документа для сбора предложений: что-то сразу отбрасывается, что-то сразу принимается, что-то принимается с условием предварительного анализа — а нужно ли это и будет ли это работать?
Это совещание — настоящая война мнений. Cпоры ведутся жаркие, каждый участник, как адвокат, отстаивает изменения, которые предлагает его отдел. Разработчики воюют за то, что реально технически реализовать, руководители проектов — за интересы своих подопечных-клиентов, техподдержка — за те жалобы, которые больше всего ее достали, отдел продаж — за предложения, которыми их чаще всего закидывают потенциальные клиенты. Бывает, что обсуждение растягивается на целый день, который эксперты проводят, не выходя из переговорной.
“Бывает что ты вносишь изменения, а на экспертном совете их не удается отстоять. Я когда познакомилась системой, сразу предлагала названия “Папки приложения” и “Папки поиска” переименовать — непонятно это звучит. И каждый раз не удавалось отстоять свою точку зрения — вроде как мелочь такая, одной тебе не понятно. Только в этом году клиенты подтвердили мою точку зрения. Мы провели конкурс среди сотрудников, были получены предложения по переименованию и “Папки приложения” наконец-то переименуются в “Папки действий”. Вроде бы ерунда, а на самом деле — важный момент в UI системы. Представьте теперь, какие баталии были когда мы обсуждали редизайн всей системы”, — рассказывает Людмила Князева, руководитель отдела маркетинга, член ежегодного экспертного совета.
Те самые «папки приложения». Пользователи видят их в последний раз.
До середины апреля необходимость всех спорных пунктов в списке выясняется. Бизнес-аналитик составляет аналитические записки, руководитель отдела техподдержки с сотрудниками проводит опрос заказчиков — нужны ли им такие возможности системы; руководитель отдела разработки проводит Research & Development (R&D) в поиске технических возможностей реализации спорных идей.
В середине апреля проходит второй экспертный совет. На нем обсуждаются результаты анализа, опросов клиентов и R&D и формируется окончательный пул задач для разработчиков. Задачи разделяются на группы, определяется их ресурсоемкость и приоритетность.
На этом этапе на первый план выходят вопросы экономики: насколько все эти изменения нужны нам и клиентам и во что они нам встанут, хватит ли у нас ресурсов на их реализацию. Решающее слово здесь остается за коммерческим директором компании (он же — руководитель направления “Электронный документооборот”).
На этом же этапе формируются экспертные группы по отдельным задачам. В экспертную группу могут войти разные специалисты, помимо разработчиков: для чего-то нужно привлечь дизайнера, для чего-то — специалиста по техподдержке и так далее. Для каждой экспертной группы формируются графики заседаний, на которых будет обсуждаться текущая работа над задачей.
Разработка СЭД: от идеи к реализации
Разработка возможностей новой версии СЭД начинается в конце апреля. До этого создается и передается в отдел разработки проект релиза с графиком ресурсов: какие нужно выполнить задачи, сколько для этого потребуется программистов и сколько часов им нужно над ними работать. В него включаются доработки, одобренные на экспертном совете, а также доработки, одобренные для прошлых релизов, но по тем или иным причинам в них не вошедшие (их предоставляет бизнес-аналитик). На этом же промежуточном этапе создается техническое описание релиза: что было изменено, и как это работает.
В это же время собирается рабочая группа, состоящая из разработчиков, документ прочитывается, задачи распределяются и в мае стартует собственно разработка системы электронного документооборота, которая продлится до середины августа. В процессе разработки экспертные группы по разным задачам заседают по своим графикам, обсуждая текущие проблемы.
«Рождение» модуля совещаний
После того, как разработчик заканчивает работу над каждой новой задачей и вносит результат в готовом виде в основную ветку системы, начинается его тестирование. Отдел тестирования проводит проверку новых изменений на работоспособность и передает список задач на исправление ошибок в отдел разработки. До середины августа ошибки должны быть исправлены.
“При тестировании нужно учитывать, что одни клиенты используют стандартное решение ТЕЗИС, другие – будут изменять и дополнять функциональность системы с помощью предоставляемых нами настроек, конструкторов и прочих возможностей. А третьи создадут самостоятельно или с нашей помощью проекты-расширения. Это диктует некоторые ограничения на добавление новых возможностей в релиз, так как мы должны «не навредить» текущим клиентам. Наши специалисты довольно глубоко погружены в бизнес-контекст клиентов, поэтому отдел принимает самое активное участие в развитии продукта в целом», — комментирует руководитель отдела качества Светлана Мельникова.
Судный день длиной в месяц: завершение разработки СЭД и подготовка к выпуску
В середине августа наступает день, когда делается code freeze — «заморозка» кода системы для изменений. Разработчики больше не могут вносить в релиз никаких новых возможностей — только исправлять ошибки. К работе снова приступает отдел тестирования, занимаясь поиском ошибок, возникших в результате исправления других ошибок (анекдотическая вещь в мире программирования — знаете известный стишок?).
Новые «придумки», возникшие в период разработки, начинают сохранять в следующий минорный (промежуточный) релиз. Туда же переносятся некоторые работы, которые сместили из за нехватки ресурсов, или внезапные предложения от отдела продаж, если их легко реализовать.
Далее стартует подготовка к выпуску релиза.
Продолжается тестирование и исправление оставшихся ошибок, и в это же время в работу вступает технический писатель, которые составляет документацию на новые «фичи», а отдел маркетинга готовит новости и пресс-релизы о выходе новой версии. В своей работе эти сотрудники руководствуются техническим описанием (его обычно составляет отдел тестирования).
В начале сентября — первая установка нового релиза: альфа-релиз устанавливается на сервер, доступный сотрудникам отдела продаж. Они должны ознакомиться с новыми возможностями системы, прежде чем рассказывать о них клиентам.
Тогда же происходит актуализация общей функциональной спецификации на систему (в документе «то, что хотели сделать» исправляется на «то, что реально сделали»). Также актуализируются частные технические задания на разработку системы электронного документооборота, которые выдавались экспертным группам (по тому же принципу).
Графический комментарий нашего бизнес-аналитика по поводу актуализации ЧТЗ
Все еще продолжается тестирование и исправление багов (уже найденных отделом продаж)… В этот же период отдел маркетинга (или техподдержки — в зависимости от загруженности) пишет документ «Отличительные особенности релиза ТЕЗИС X.X», который впоследствии будет рассылаться существующим клиентам.
Вскоре отдел продаж получает обновление альфа-релиза с исправленными ошибками, а отдел тестирования актуализирует документ «Техническое описание релиза» и приводит его в вид, в котором его можно будет показать клиентам.
Середина сентября — вторая установка нового релиза: обновляется внутрикорпоративная СЭД ТЕЗИС. Да, мы сами используем свою СЭД и считаем, что первыми должны испытать все изменения на себе, прежде чем предлагать их клиентам.
К концу сентября завершает работу отдел маркетинга: рассылаются новости и пресс-релизы о готовящемся выпуске системы, актуализируется информация о возможностях системы, и демонстрационные материалы и видеоролики на сайте.
В это же время отдел продаж проводит вебинары, на которых новая версия системы представляется на суд сначала партнерам, а потом — клиентам.
К концу месяца завершается тестирование. К этому же моменту должны быть готовы инструкции к системе. Подготовка к «дню рождения» системы завершена.
Полноценный релиз: представление результатов разработки СЭД клиентам КЛИЕНТАМ
Система ТЕЗИС выходит в релиз 30 сентября или 1 октября — к примеру, ТЕЗИС 4.1 вышла 1 октября 2015 года. Так что по гороскопу наша СЭД ТЕЗИС, очевидно, Весы.
С этого момента разработка системы электронного документооборота заканчивается, отдел техподдержки начинает обновление системы у заказчиков.
До середины октября обновляются «малые» заказчики — те, кто приобрел Базовую или Стандартную редакцию СЭД ТЕЗИС, то есть, стандартную «коробку» системы или систему с минимальными изменениями. Обновление для таких клиентов проходит быстро и стандартизированно в установленные дни.
В ноябре обычно обновление начинают получать «крупные» заказчики — пользователи Расширенной редакции с существенными доработками.
В этот период начинает поступать обратная связь от клиентов — новые идеи, которые будут «копиться» до следующего релиза. Или в процессе разработки в следующем году будет выпущен минорный релиз — промежуточный релиз системы, включающий в себя исправления и изменения специально по запросам клиентов, которые тщательно собираются и анализируются. На данный момент это ТЕЗИС 4.1.4.
Таким образом, разработка системы электронного документооборота ТЕЗИС ведется строго по графику. И это естественно — мы должны уметь дисциплинировать себя, чтобы потом эффективно наводить порядок в документообороте наших клиентов. В настоящий момент полным ходом идет подготовка к выпуску релиза ТЕЗИС 4.2.
Поделиться с друзьями
Комментарии (10)
ncix
22.09.2016 14:42В середине августа наступает день, когда делается code freeze — «заморозка» кода системы для изменений. Разработчики больше не могут вносить в релиз никаких новых возможностей — только исправлять ошибки.
Какая же это заморозка, код-то правят и дальше. Изменения в коде при исправлении ошибок принципиально ничем не отличаются от изменений для нового функционала
Также актуализируются частные технические задания на разработку системы электронного документооборота, которые выдавались экспертным группам
А это зачем, простите? Кому эти ТЗ потом нужны?
А что делают разработчики в «межсезонье»?
Если честно, итерации выглядят не очень симпатично, очевидно много бумагописательства и бесконечных совещаний и согласований. Не думали перейти на более короткие итерации, скажем в 3 месяца? Месяц?
lyusion
22.09.2016 15:25Какая же это заморозка, код-то правят и дальше. Изменения в коде при исправлении ошибок принципиально ничем не отличаются от изменений для нового функционала
Проблемы с code freeze известны всем разработчикам ПО, поэтому вернее сказать об ограничении изменений кода и ужесточении контроля за ним. Таким образом из двух типов замораживания — полное и замораживание функциональных свойств, мы используем второй тип.
А это зачем, простите? Кому эти ТЗ потом нужны?
Проект растет и развивается. Приходит новая команда. Появляются новые «хотелки» от клиентов. Всегда удобнее работать, если есть актуальная документация на все фичи.
А что делают разработчики в «межсезонье»?
Компания выпускает не только стандартное решение. Проектная команда работает с продуктами, которые ориентированы под конкретных заказчиков. Работы мало не бывает.
Что касается бумагописательства, то мы, как адепты электронного документооборота, несколько модернизировали этот процесс. Он не настолько затратен по времени, как может показаться. Переход на короткие итерации несет большие потери времени на регрессионное тестирование продукта.ncix
22.09.2016 16:27Проблемы с code freeze известны всем разработчикам ПО
Проблема в том, что никакого freeze нет и быть не может, пока проект жив. Просто эта красивая но несуществующая абстракция нравится некоторым РП и тимлидам.
полное и замораживание функциональных свойств, мы используем второй тип.
Т.е. фактически не все из того что было запланировано может быть реализовано? А кто определяет, на какие задачи можно забить? Снова большой совет?
Всегда удобнее работать, если есть актуальная документация на все фичи.
Так вы выше упомянули что тех.спецификацию тоже актуализируют.
Переход на короткие итерации несет большие потери времени на регрессионное тестирование продукта.
Это правда. Если тестирование слабо автоматизировано ;) Я не говорю сейчас про юнит-тесты, они по-идее не тестировщиками делаются.
Имею в виду автоматизированное функциональное (или интеграционное) тестирование. Нам в свое время это здорово разгрузило отдел тестирования, да и тестирощики из кнопконажимателей прокачались до крутых спецов по автотестам.lyusion
22.09.2016 21:20Т.е. фактически не все из того что было запланировано может быть реализовано? А кто определяет, на какие задачи можно забить? Снова большой совет?
Подразумевается, что всё, что было начато, доводится до логического завершения. Если мы что-то обещали клиентам, то это будет сделано в первую очередь. Остальные запланированные, но не реализованные по разным причинам новшества, могут перейти в будущие релизы. Планирование работ и оценка ситуации выполняется еженедельно и набор фич, что мы не успеваем сделать, мы знаем задолго до code freeze.
Автоматизация тестирования — действительно камень преткновения. Отчасти, это правда. Работа в этом направлении ведется.
EvgeshaH
23.09.2016 11:30Хотелось бы написать пару слов про текущий Reminder. Мы начали пользоваться тезисом недавно и пока идет процесс интеграции.
Как мне кажется, в большинстве компаний, где разворачивают СЭД, есть домен. Так вот Reminder пока не доделан для нормальной развертки в домене.
1. Поставляемый MSI задает «лишние» вопросы и препятствует тихой установке, поэтому через групповые политики вы его не развернете.
2. Сам Reminder требует установленной java. Устанавливать java на все компьютеры очень плохо, как минимум из-за её постоянных обновлений, которые не разослать централизованно, через тот-же wsus (Да, она умеет сама! Но при обновлении просит права админа). Очень ждем когда сделают реализацию на .net (который есть на любой windows без установки). Или может даже web push
3. Он не поддерживает Office 2016. И когда начнет поддерживать не говорят. А офису 2016 уже год.
4. В Outlook'е непонятно как и когда сохраняет свои настройки. Очень часто не сохраняет. Особенно страдают пользователи с небольшими мониторами, которым мешает постоянно открытая панелька тезиса.
5. Сам Reminder не умеет запускаться свернутым, хотя разработчики нас уверяют, что умеет. Задача помощника тихо сидеть в трее, и напоминать о себе только когда придет какое-нибудь уведомление.
6. Помощник не умеет «по-умолчанию» авторизовываться с доменным именем текущего пользователя.
Некоторое из написанного (п. 1, 6) решилось только после того, как разработчики сделали специальную сборку под нас, за что компании спасибо.lyusion
23.09.2016 11:34Спасибо за отклик, это справедливые замечания. Как я уже упоминала, мы стараемся выполнить то, что обещано клиентам, в первую очередь.
Поэтому, что касается пунктов 1, 3 и 6, это уже в новом релизе поправлено. Во вновь поставляемых инсталляторах проблема с автообновлением Java решена (п.2).
А п.4 и 5 будут проработаны и постараемся решить озвученные вами проблемы. Благодарим за участие в развитии продукта.EvgeshaH
23.09.2016 11:57Сейчас проблема с Java решена самым удивительным образом! Внутри дистрибутива Reminder'а лежит «своя» Java (200 МБ), которая ставится в папку с Reminder'ом и он её использует. Эта java никак не обновляется, и будет всегда такая, какую её положили.
Все же лучше иметь версию под .Net, благо не так много функций у программы, и реализовать их не долго.
Или сделать универсальное решение на web push, которое даже на смартфонах работать будет. Тогда даже устанавливать на компьютер ничего не нужно.lyusion
23.09.2016 14:43Java будет обновлена при необходимости в следующей версии Помощника.
На данный момент мы считаем существующий вариант реализации наиболее приемлемым с учетом кроссплатформенности приложения.
Подумаем насчет уменьшения дистрибутива.
Bonfin
Получается, что мы пролетаем с обновлением, раз его должны установить до 1 октября?
А сделать нормальный инсталлятор Reminder-а так и не смогли…
lyusion
С 1 октября только начнутся обновления, поэтому опоздать куда-либо маловероятно.
А что не так с инсталлятором Reminder-а (с 4.1 tezis-assistant)? Каждый релиз это улучшение продукта, в новой версии были работы и по улучшению инсталлятора. Если вдруг есть идеи, мысли, предложения, то всегда готовы выслушать.