Блог Александра Башкирова

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

рассуждение

Подписаться на эту метку по RSS

Пост про то, как надо писать ТЗ

Периодически мне приходится в том или ином виде консультировать разные компании по поводу такого замечательного документа, как техническое задание на информационную систему.

И часто встречается ситуация, когда в роли ТЗ выступает все, что угодно... кроме, собственно, ТЗ. Почему так? Да потому, что ТЗ - это задание, на основании которого должна быть подготовлена система автоматизации. Не более - но и не менее. В роли ТЗ в общем случае не могут выступать прототипы экранов, список пожеланий и т.д. - потому что в итоге получится нечто, соответствующее ТЗ - но полностью или частично не соответствующее ожиданиям заказчика. Как избежать такой радостной ситуации?

Во-первых, всегда помнить - система, разрабатываетмая по ТЗ, автоматизирует процесс (напомню, речь идет о ТЗ на информационную систему - от интернет-магазина до ERP). Соответственно, в ТЗ обязан быть прописан процесс, который автоматизируется. Иного просто не дано: не понимая процесса, невозможно описать систему.

Второй аспект: ТЗ должно описывать результат "на выходе". И из этого следует еще один очень важный вывод: в ТЗ должны присутствовать варианты использования системы. То есть, должно быть описано, кто (какая роль) выполняет какой надор действий в системе. Да, и это должно коррелироваться с процессами, которые система автоматизирует.

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

Дальше имеет смысл расписать требования к формам и дизайну. Требования к формам, в идеале - это выделение критически важной информации длдя процесса, с анализом - когда, кто и в каком объеме поставляет нужную информацию. Требования к дизайну тут получаются вроде бы как не очень логичны... но логичны, потому что важно не только то, что будет нести форма в себе - но и то, как она будет выглядеть. Хотя требования к дизайну можно вообще поставить в конец ТЗ, или сделать ссылку на brandbook - тут вариантов масса.

Следующее, что нужно для разработки ИС - определить этапность. Что делаем и что запускаем в первую очередь, что - во вторую и т.д. Это очень важно - так как позволяет четко очертить пожелания Заказчика к тому, что должно работать в первую очередь, а что должно быть запущено в последнюю очередь. Кстати, если есть сроки - то им место тут же.

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

Дальше, моделируем ситуацию, когда готов прототип. В ТЗ на этот случай надо указать, кто и как тестирует, желательно - порядок работы с замечаниями (по хорошему, это в устав проекта идет, но на край можно и в ТЗ).

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

Дальше приводятся так называемые "потребительские характеристики системы" (время отклика, число кликов по основным операциям и т.д.). И приводится то, что влияет на эти характеристики - например, конфигурацию серверного оборудования, операционные системы, лицензии и т.д.

Дальше, прописываются требования к тому, что будет включено в понятие "результат". То есть, что и в каком виде будет передано Заказчику - документация, исходные коды, скомпилированные модули и т.д. Исходя из этого, следующий логичный пункт - состав и структура документов, которые будут переданы Заказчику по окончанию процесса разработки / внедрения. Тут имеется в виду как "пользовательские" документи, такие, как ролевые инструкции, инструкции по профилактике, обслуживанию, устранению типовых ошибок и т.д., так и общетехнические документы - описание архитектуры решения, проектная документация.

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

Получилось довольно много? Да, а кто говорил, что будет просто? На данный момент я написал, наверное, более сотни разных ТЗ - и по итогам работы над этими докумнетами пришел к выводу о том, что если писать документ не ради документа, а ради работы - то он по любому получится большим. Не потому что я так хочу, а потому, что по-другому просто не получится. Тут или качество, или расходящийся процесс.

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.

Классическая ошибка "крайнего события"

Просмотров: 2371Комментарии: 2
Alib.spb.ru

Вспомните, как заканчиваются сказки: "они жили долго и счастливо, и умерли в один день". О чем это? Да о том, что все, герои выполнили свое предназначение - иван-дурак нашел Василису Премудрую... ну а дальше вы все знаете. Долго и счастливо. Ага.

Нет, самое интересное для меня лично в том, что счастливый (а кто бы спорил) брак рассматривается как некое "крайнее событие". Типа, вот - все. женились, и дальше "хорошо по умолчанию". Хотя порой проблемы тут как раз и могут начинаться. А могут, кстати, и не - свадьба, она дело такое... но в целом я не про свадьбу.

Ведь та же проблема "крайнего события" возникает часто и в жизни. В самой простой ситуации - "вот, дожить до - и тогда...". Фактически, каждый человек хоть раз да бывал в шкуре такого "крайнего".

Но, как мы помним - жизнь богаче наших о ней представлений. И на поверку "крайнее событие" оказывается совсем не крайним. А просто одним из событий в веренице жизни. Еще Высоцкий (а это, на секундочку - прошлый век) пел: "ведь мы, отдав концы, не умираем насовсем"... не знаю, как там, в жизни загробной (достоверно про нее мне известно мало), а вот в этой, реальной для нас жизни - любое событие можно и нужно трактовать в канве "одно из".

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

В общем, поток сознания :)

Размышления про почтитать

Просмотров: 2856Комментарии: 2
Книги

Все сложнее и сложнее становится найти хорошую книгу. Хорошую - в смысле, интересную. Не жвачку для мозга, а именно - чтобы подумать. Для ума. Да так, чтобы не оторваться, читая запоем.

Но такого - мало. Можно, конечно, почитать нестареющую классику - но она мало в чем меня трогает, специфические вкусы. Например, у Набокова самой сильной вещью считаю "Приглашение на казнь", а не воспеваемую всем "Лолиту", мне отккроенно нравится Бродский и Павел Васильев (тот, который поэт 20х годов 20ого века). Ну и т.д.

В последнее время плотно подсел на Мирчу Элиаде - румынского философа. Интересен он не только своими философскими текстами, но и тем, что дает массу "сопутствующей" информации. То есть, рассказывает о мифах - и о временах и странах, которые сопутствовали мифу. К концу "Аспектов мифа" у меня вообще сложилось ощущение того, что человек этот - ходячая энциклопедия.

Еще раз перечитал "Розу Мира" Даниила Андреева. Когда-то (лет в 16) она мне казалась чуть ли не откровением. Сейчас - просто красивая большая сказка...

Так вот, я пытаюсь искать интересные книги. Способ понять, "интересная" книга или нет в общем один - начать ее читать. И я регулярно скачиваю кучу книг, читаю - и определяю, что интересно, что нет. Обычно получается "не интересно", то есть не обычно - но чаще.

При этом, смотрю на рейтинги книг в библиотеках - и тихо балдею. Так как то, что "не интересно" часто имеет большой рейтинг, то, что "интересно" - маленький. Пример - тот же Мирча Элиаде. Про которого пишут, что "непонятно", "читать невозможно", "скучно" и тд.

Что-то меня такая тенденция настораживает...

С 9 до 18ти

Просмотров: 3229Комментарии: 0
Работа
Предупреждение: все, что написано ниже - касается исключительно работы в сфере ИТ. 
В последние дни февраля хочу поговорить на непростую тему. За что мы работаем?
Вернее, не так. За что - понятно. За деньги. 
А вот как мы это делаем...
Я встречал компании (вполне себе солидных интеграторов и не менее солидных провайдеров), в которых график работы (с 9 до 18, с перерывом на обед, ну или вариации - с 8 до 17ти и т.д.) - возведен в ранг священного постулата.
Что в итоге? А в итоге, народ начинает относиться к работе "по-советски" (в худшем смысле слова) - "я не работаю - я провожу время на работе за деньги".
То есть, с одной стороны, жесткое время пребывания на работе заставляет переориентироваться с работы на время. Что в общем не верно. 
Лирическое отступление. "Тупая" ориентация на результат (я видел и такие компании) без оглядки на время - тоже не сахар.
С другой стороны, ориентация на результат к сроку (если результат и срок разумны) с "мягким" ограничением по времени (присутствие в офисе с 11ти до 16ти, например) - выглядят довольно разумно.
У меня есть хороший опыт проектной работы. И мне сложно представить, КАК я бы работал, будучи загнан в пресловутые рамки "9 - 18". Дело в том, что проект по загрузке по времени нелинеен. Бывают "пики", бывают "спады". И работа (моя, по крайней мере) иногда может позволить "свалить" на пару часов пораньше - а иногда требует ночных бдений. Что примечательно - итоговый результат по времени получается "примерно-нейтральным". То есть - 40 часов в пересчете на неделю в перспективе 3..4 месяцев.
Тут еще надо сказать, что работать вне схемы "9 - 18" могут люди с высокой степенью самоорганиции. Потому что в ином случае получится бардак, и лень.
Да, еще ремарка. "В схеме" или близко к тому могут и должны работать те, у кого характер работы подразумевает подобную работу (простите за тавтологию) - то есть, например, системные администраторы, операторы баз данных, служба поддержки и т.д. То есть те, кто работает с постоянной, прогнозируемой загрузкой и понятными задачами.\
Сумбурно получилось.
А вы строите вашу работу?

Bluetooth гарнитуры для обычных телефонов

Просмотров: 2804Комментарии: 0
Alib.spb.ru

Совершенно дурацкий вопрос: почему до сих пор не придумали (или не сделали) Bluetooth гарнитуру для обычных телефонов? К вопросу "зачем, когда есть dect" могу сказать следующее:

  • если Bluetooth будет на дектовской трубке, то сиитуация полностью аналогична мобильному - трубка на поясе (в кармане, в углу) - гарнитура - на ухе, руки - свободны
  • если Bluetooth будет на аппарате, то опять-таки: гарнитура - на ухе, руки - свободны

Непоняненько, однако...