Данный блог не ведется с 2014 года.
Если вы вышли на этот блог по поиску гугла и у вас есть что спросить по теме как оформлять те или иные проектные решения в бумагу для условного ГОСТ34 - пишите комментом к этой записи или в личку

Монблан. 6-14 сентября 2014

Текст не в тему блога, но надо же его кудато положить

11 сентября 2014 года я успешно взошёл на Монблан и успешно с него спустился. Ниже по тексту я описываю свое восхождение и привожу зарисовки для будущих любителей по подготовке и подбору снаряжения и питания.

Правильные вопросы кандидату на системного архитектора

Жизненное наблюдение
Как понять что кандидат подходит именно на архитектора, а не пресейла, продавца, инженера и тп....

Попросить сначала придумать решение, а потом попросить показать план реализации с оценкой трудоемкости, времени и ресурсов.

Правила и методика испытаний. Логичная схема разработки документа

Каждая АС должна иметь документ Правила и методика испытаний.
Разработка части Программа испытаний формализована и достаточна проста. Достаточно идти по пунктам РД50 и просто описывать в формате регламента.

Методики испытаний сложнее и многогранее -)
Метаний с ними много бывает. Согласования также выводят нас на кривую дорожку излишней детализации.

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

Итак...
Главная цель данной методы - сократить трудозатраты, объем описания и уложить ПМ в общую канву ТРП.

Канбан руководителя или как по стопятьдесят раз не объяснять кто что делает и за что отвечает - схема областей деятельности

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

Зачем нужен ITSM - а вот зачем!

Я - это парень с пулеметом, когда я продаю системы автоматизации ИТ процессов и мониторинга

ГОСТ 24 - Технико-экономическое обоснование (ТЭО)

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

Назначением ТЭО является - дать возможность заказчику обосновать выделение денег у "бюджетодавателя" на ваш проект. Другими словами - ТЭО это бюджетная заявка с обоснованием. Из этого следуют следующие важные для понимания вещи:

1. ТЭО инструмент продажи
2. ТЭО не противоречит и не участвует в процессах PMBook
3. ТЭО задает границы бюджета и состава работ
4. ТЭО пишется заказчиком, но пишите его вы - исполнители
   

Майндмап для проектирования систем кастомного мониторинга

Мандмап служит мне шпаргалкой при начале работ, в первую очередь, сбора сведений и требований, на системы мониторинга не из коробки.

Во вторую очередь данная схема дает хорошее представление о структуре информационного обеспечения АСУ. Если есть необходимость писать данный проектный документ, конечно.
Хотя именно П5 является тем самым документом, за счет которого без больших проблем можно набрать необходимые брутто-тонны технического проекта.

Майндмап регламента резервного копирования

Для каждой АС должен быть разработан регламент резервного копирования данных и их востановления. Это часть обязательно и даже регламентируется в ТЗ по ГОСТ34.