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