“Русские” вопросы

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

Кто виноват?

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

Отсутствие пользователей

Пользователей сначала надо найти. Как же так? Разработчик старался, делал программу, отлаживал её, прикручивал разные фичи, ночами не спал и сделал таки свой самый лучший на всем белом свете проект. А пользователей нет. А если и есть, то платить за программу они не торопятся. Конечно, если программа была создана по конкретному запросу конкретного человека или организации, то такой проблемы нет, но если вы хотите иметь постоянный доход, который напрямую не зависит от количества часов, проведенных за клавиатурой, то рано или поздно вы захотите создать универсальную программу, в которой нуждаются сотни и тысячи (а лучше – миллионы) пользователей по всей Земле. И вот, когда ваш гениальный продукт готов, то выясняется, что вам требуются услуги маркетолога и обильные вливания в рекламу…

Недовольные пользователи

Но вот пошли скачивания, установки и начался серый унылый дождь из однообразных вопросов: “А как сделать это? А как сделать то? А у меня не получается…” Сначала вы отвечаете на них сами, но трезво оценив свои возможности, создаёте форум, на котором находятся продвинутые пользователи, выполняющие за вас эту работу. А если их нет, то требуются новые затраты на оплату услуг специалистов техподдержки…

Пользователи-вандалы

По мере роста числа пользователей выясняется, что не все они белые и пушистые. Некоторые из них начинают нажимать все кнопки подряд, вводить невероятные параметры настроек, загружать немыслимое количество данных, а потом присылать сообщения о том, что программа приказала долго жить. Только вы хотели посидеть спокойно на лаврах, ан нет – нужно либо самому заниматься тестированием, разбирая баг репорты, либо нанимать тестировщиков. И как только вы нашли и устранили 90% ошибок (а иногда и раньше), находятся самые опасные пользователи:

Фантазёры

Они действуют из благих намерений сделать мир (и вашу программу в частности) лучше. Для этого они предлагают различные на их взгляд нужные доработки. И вы снова бросаетесь на штурм крепости под названием “Лучшая программа в мире”, применяя хитроумные алгоритмы и добавляя новые компоненты. И тут же получаете прирост в рядах недовольных пользователей и пользователей-вандалов.

Справедливости ради нужно заметить, что на первом этапе (отсутствие пользователей) фантазёры играют положительную роль, так как именно они помогают вам в продвижении продукта на рынок, делая его более функциональным и ценным. Но в какой-то момент проект может потерять целостность и стройность, и вы сами уже с трудом будете понимать, что же он может делать, а чего не может…

Что делать?

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

Универсальный солдат

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

Автоматизация кодирования

Инструменты должны максимально облегчать вашу работу. Всё, что можно автоматизировать, нужно автоматизировать: создание пользовательского интерфейса, создание и модификацию структуры данных приложения, обновление версий и так далее. Это не увеличивает функциональность системы или её ценность в глазах пользователей, но это дает вам шанс сохранять контроль над процессом производства с минимальными усилиями и максимальным качеством. Рассматривайте такие работы как долгосрочные инвестиции.

Автоматизация тестирования

На этапе реализации проекта на кодирование уходит около 20% времени, всё остальное тратится на тестирование. Возможно, на первой итерации пропорции будут другими, но с увеличением сложности функциональности и объема исходного текста, время на проверку работы системы будет расти. А когда число внутренних взаимосвязей между компонентами превысит некую критическую отметку, одним ручным тестированием добавленной фичи уже не обойтись. Используйте различные виды автоматического тестирования, а если это возможно, встраивайте в систему элементы самотестирования.

Автоматизация документирования

Документирование проекта – самая непопулярная тема среди разработчиков. Глядя на свой идеальный код, они рассуждают: зачем что-то документировать? Ведь тут и так всё понятно! Через полгода они могут поменять своё мнение, но время будет упущено. Самодокументированный код не является панацеей, хотя и облегчает поиск ошибок и доработку. Нужны системы, автоматизирующие процесс документирования проекта. Требуется ведение как внутренней документации, так и документации для пользователей.

Командная игра

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

Итоги

Хотя в разделе “что делать” мной были перечислены несколько направлений, в первую очередь я хочу обратить внимание читателей на процесс документирования. И вот почему.

Отсутствие пользователей часто вызвано отсутствием информации о программном продукте: требуется создание различных документов, которые бы описывали его преимущества, его возможности и так далее. Таким описанием может стать один из разделов инструкции пользователя, который можно цитировать на форумах, пабликах, социальных сетях и других местах продвижения программы.

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

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

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

Таким образом, мои варианты вопросов-ответов будут такие:

• Кто виноват? – Разработчики!
• Что делать? – Документацию!

Dr.Explain

Для себя я нашел удобный инструмент документирования – dr.Explain. В одном проекте он содержит всю информацию, которая необходима для создания различных представлений документации: веб-сайт с онлайн документацией, файл для системы помощи Windows, PDF-формат для печатного вида или универсальный RTF-формат для использования в альтернативных вариантах документирования или публикации данных.

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

Dr.Explain предоставляет широкие возможности для редактирования контента. Редактор поддерживает текст с различными начертаниями и стилями шрифтов, аннотированными изображениями, видео, таблицами, нумерованными и произвольными списками, гиперссылками, макропеременными и специальными объектами. А встроенная проверка орфографии с национальными словарями поможет вам избавить текст от опечаток и ошибок.

Хотите поставлять руководство с программным обеспечением и сделать контекстно-зависимую помощь? Вы можете легко связать документацию с программой с помощью Dr.Explain, чтобы создать контекстную справку. Dr.Explain поддерживает механизм Help ID, автоматически присваивает и импортирует идентификатор справки, а также генерирует map файлы идентификаторов справки.

Пример интегрирования справки в проекты My Visual Database рассматривается в статье “Help!”.

Ссылки

• Dr.Explain – программа для быстрого создания файлов справки (help-файлов), справочных систем, on-line руководств пользователя, пособий и документации к программному обеспечению, изделиям, техническим и бизнес-системам.
• My Visual Database 6.5 – простая среда разработки приложений; без помощи специалистов и навыков программирования вы создадите приложение для работы с базой данных.
• 10 лучших инструментов для автоматизации тестирования ПО – статья Ю.Ефимова о средствах автоматизации тестирования, в том числе – бесплатных.

P.S. В данной статье рассматривается только один из возможных вариантов ответов на извечные вопросы программистов (и не только) что делать и кто виноват. В реальной жизни вариантов гораздо больше и не все они так однозначны.