Недостаточно просто написать и протестировать программу.
Случалось ли с вами, что после запуска программы увольняется сотрудник, который долгое время с ней работал? Или возникла необходимость улучшить программу, но никто не помнит, как она работает? Продолжение Знаете: все начинают лихорадочно вспоминать, что это за программа, как она работает, где все хранится и откуда берется и т. д. Согласитесь, подобные ситуации случаются с завидной частотой и происходят постоянно.
Если на программу нет нормальной документации, то восстановить ее внутреннюю структуру может быть очень и очень сложно.
А иногда это даже приводит к серьезным ошибкам или полной остановке процесса.
Поэтому хорошей практикой является хотя бы создание простых инструкций по использованию (которые для скорости можно заменить, например, скринкастами).
Однако есть один момент, на который мало кто обращает внимание.
Давайте рассмотрим это на конкретном примере.
Представьте, что вы создали каталог городов России, который используется, например, при регистрации на вашем сайте.
Все работает нормально, но проходит год-полугода и названия многих городов меняются (это вполне реальная ситуация - названия населенных пунктов меняются постоянно).
Как вы об этом узнаете? Что вы будете делать, когда обнаружите это?
Что тогда? Суп с котом?
Будете ли вы ждать, пока пользователи начнут присылать вам гневные письма с вопросом, куда вы поделили их город? Вряд ли вам это интересно, правда? Поэтому недостаточно просто сделать справочник.Также необходимо предвидеть, что с ним будет потом, после ввода в эксплуатацию.
Причем эта часть оказывается неожиданно важной и достаточно трудоемкой.
Но это обязательно нужно сделать! Разберем пример со справочниками до конца и продумаем процедуру их обновления.
Обновить каталог можно двумя способами: автоматически и вручную.
Конечно, выгоднее всего обновляться автоматически, но зачастую этого недостаточно.
Представьте, что источник, из которого вы получаете список городов, сломался — перестал обновляться или произошла ошибка.
Если ошибку еще можно как-то обнаружить (например, автоматической отправкой писем админам), то прекращение обновления никак не будет обнаружено (ведь ошибки нет, а информация не обновляется) Поэтому правильнее выделить специального человека, который будет в курсе этого справочника и сможет определить, что это неправда.
Ух ты! Задача растет. Этот человек должен отвечать за периодическую проверку каталога или, что еще лучше, добавлять задачу в свой календарь и писать инструкции, что делать при обнаружении проблемы.
А чтобы через год вспомнить, как работает каталог, стоит записать информацию о нем на вики: как работает модуль, где и как хранится информация в системе, кому отправляются письма, ссылка на технические характеристики, какой человек нужен для его поддержки и каковы его обязанности.
В результате получается полноценный бизнес-процесс.
Полученные результаты
Как видите, недостаточно просто написать и запустить программу.Обязательно подумайте, что будет с вашей программой дальше: как она будет использоваться, как поддерживать ее в актуальном состоянии и как действовать в экстренных ситуациях.
Обычное возражение против этого: недостаточно времени.
Да, времени действительно никогда не хватает, но подумайте, сколько времени вы потеряете потом, когда вам нужно будет срочно что-то сделать.
Поверьте, потери будут гораздо выше и дороже, чем сейчас, когда программа только создавалась.
Попробуйте вместо текстовых инструкций делать видео-скринкасты — это быстрее и проще.
Если вы хотите сделать готовый продукт и проявить заботу о своих пользователях и коллегах, подумайте, что будет после того, как ваша программа начнет работать.
Просто составьте небольшой контрольный список и используйте его для каждой своей программы.
И удачи в работе! Теги: #разработка ПО #документация #Управление проектами
-
Делать Покупки Через Интернет Весело
19 Oct, 24 -
Локальная Межзвездная Среда
19 Oct, 24 -
Кроссплатформенный Хабр
19 Oct, 24 -
Блеск И Нищета Российского Онлайн-Шопинга...
19 Oct, 24 -
О Градиенте Изображения
19 Oct, 24