Документация убогая, когда пишущий:
— плохо умеет выражать мысли на русском языке
— ленив или слабо мотивирован
— слабо разбирается в предмете описания
— не владеет всем объемом исходных данных по независящим от него обстоятельствам (например, не подогнали вовремя описываемый модуль)
Когда все пункты выполнены, документация получается отличная. Даже в тисках структуры ГОСТа
Да, есть явный конфликт между структурой ГОСТ и требованиями по «эргономике текста». Наверное, лучше все-таки, иметь стандартное РП и параллельно инструктивный материал по ролям участников процесса (некая разновидность технологической инструкции). В свое время я экспериментировал со свободной формой. Не всем она по душе и не все разделяют энтузиазм создателей системы.
По внутренней документации. Даже в нашем маленьком стартапе программисты не могут работать без постановок, которые готовят аналитики. У программистов нет фантазии, им это вообще не нужно. Постановка может содержать уже и Use Case, и эскизы интерфейсов и все, что угодно, чтобы программист понял задачу.
По книжкам. Документация по ГОСТ сделана таким образом, что она может появляться вместе с системой, параллельно. Не думаю, что популярную книжку можно написать до того, как появится предмет описания. А вот потом, глядя на готовую систему и (убогую) документацию к ней, можно уже выдать любой материал для любой аудитории, с картинками и цветными врезками.
Да, свободный рынок как-то не очень работает. Я, например, ни разу не менял работу через агентство. Все время по знакомству переводился. А теперь вообще командой кочуем. Несколько раз делал попытки собеседоваться через ХХ. Бесполезная трата времени. Кадровикам непонятно, за что мне вообще деньги платят. Так на любой работе, связанной с «высшими материями», где нужно не формальное соответствие, а адекватность.
Проще всего принять на работу админа начального уровня. Он только в дверь входит, а я уже знаю, подходит чувак или нет :). А вот с другими не так просто.
Посмотрите мой материал на Хабре по американскому стандарту ИТС. Они там даже функциональные требования стандартизировали, а не только формы документов. Потому что транспортные системы, выполненные по стандарту, помогут дяде Сэму организовать эвакуацию целых штатов, управлять дорожным движением всей страны, контролировать транспортные потоки и еще много вкусностей для Большого брата. Ради этого стоит потратиться на разработку стандарта и требовать его исполнения.
Статья и так распухла до безобразного размера, чтобы ее наполнять еще и описанием жизненного цикла. Это будет уже книжка, а не статья.
Во что я твердо верю, это в то, что при желании и ясном представлении цели можно сделать очень многое. Даже безо всяких стандартов. У нас в стране светлые головы еще не перевелись.
По п.1 есть еще документ «Состав выходных данных (сообщений)», куда можно поместить все необходимые эскизы. Там же обычно живут и отчетные формы.
По п.2. Часто приходится автоматизировать несуществующие бизнес-процессы. Чтобы опираться хоть на что-то, придумывается некий виртуальный бизнес-процесс, под который пишутся технические документы. Это ненормальная ситуация, но встречается сплошь и рядом. В нашей стране все еще свято верят в то, что с помощью хитрой программы можно решить проблемы бизнеса.
Есть типовое решение подобных вопросов, которое я знаю (оно не обязательно верное). Далее субъективное мнение.
О пользе эскизного проекта я не слышал. Образно говоря, ЭП нужен для изъятия дополнительных дензнаков у заказчика. Вам в итоге можно ограничиться двумя(тремя) документами.
Пишете Пояснительную записку к техпроекту (П2), куда включаете необходимый вам контент в виде разделов по РД50 и руководство пользователя по ГОСТ. Если у вас приложение сложное в обслуживании, сделайте еще Руководство администратора (отдельная книжечка). По сути это просто глава из РП, но так будет проще согласовывать. Заодно там будет минимально необходимый технический контент стадии РД (см. ГОСТ 34.602)
Если заказчик вдруг запаникует и заговорит о ГОСТах, вы раздергаете контент П2 на отдельные «обеспечения» и все будет хорошо.
Спасибо, реализовал давний замысел зафиксировать накопленные знания. Теперь буду ссылку давать на свой же топик вместо того, чтобы по сто раз одно и то же объяснять :)
Тут вопрос, видимо, именно в сравнении. До этого я налегал на анализ и обобщение опыта, что интересует многих специалистов. А тут выдал спорное субъективное мнение в шутливой манере, которое тем же людям совершенно не интересно.
Так что критика вполне обоснованная. Аудиторию обламывать нехорошо.
Есть личная неприязнь к тому, во что превратили консалтинг у нас в стране. Дело тут не в дорогих вещах и побрякушках. К слову, в МакКинзи стараются не носить часы вообще. Потому что для кого-то штампованный Tissot — идеал совершенства, а для кого-то — нищебродская дешевка. То же самое относится к зажимам на галстук. Так что описаны именно рядовые чуваки. И писано маслом с натуры.
У нас принято называть консультантами и тех бедолаг, что настраивают какой-нибудь SAP. Такая же терминологическая путаница, как и со словами «менеджер», который и после курса MBA, и который в магазине к покупателям пристает.
Консультант — это человек, помогающий бизнесу клиента. Поэтому он фигура ритуальная, полумифическая. Он должен соответствовать локальным представлениям об успехе. Если для нас это айфон и паркер, то у него это все должно быть.
К олигарху с айфонами не пойдут, конечно. На том уровне приличному человеку вообще иметь телефон неприлично, когда есть секретарша.
Был на Tech-Ed в Барселоне в 2007 году. Потом сразу поехал на Платформу в Москве (я тогда активно админил и пер на горбу большой кусок корпоративной инфраструктуры, а начальство хотело как-то промотивировать). Так вот, то, что было в Барсе — это реально крутое мероприятие, по сравнению с тем, что мы привыкли видеть в Москве (а на Платформе я бывал до 2007 года регулярно). Все технологии можно было пощупать своими руками и послушать людей, непосредственно их разрабатывающих. Чего стоила лекция того же Русиновича, многочисленные мастер-классы, и круглые столы, где разработчики получали непосредственные рекомендации от пользователей. Да, еще была выставка с морем халявы. Я там выиграл iPod, например :)
Короче, если то, что задумал MS в Москве это то же самое, что было в Барселоне, 18 тыр нормальная цена. Туда же входят обеды (включая попойку на выставке), пользование всей инфраструктурой и много чего еще.
Лучший праздник для гика, честное слово. Особенно, если вы интересуетесь или работаете с технологиями MS.
Я так понимаю, речь в статье идет о внутренних проектах. То есть, о тех, которые являются частью развития компании. То есть, отношение руководства и сотрудников к таким проектам является индикатором отношения к развитию компании вообще. Если компания нацелена на развитие, в рабочем времени сотрудников предусмотрена загрузка по внутренним проектам. Более того, я встречал компании, в которых у многих сотрудников почти вся деятельность состояла из внутренних проектов. Курировались проекты также с самого верха. В тех же компаниях, которые перешли с фазы роста на фазу «дойных коров» (см. стратегический менеджмент) акцент с развития смещается на выжимание максимального количества денег, так как они оплачивают рост других компаний холдинга или стройку века дачи босса в Каннах.
Это я все к тому, что не все йогурты одинаково полезны :)
Я тоже не люблю писанину и бюрократию. Но это не идеальный мир, а реальная практика. Некоторых заказчиков оказалось просто не побороть. Особенно если это госсектор. Некоторые говорят открытым текстом: «Нам все равно, сколько это стоит. Нам главное, чтобы все было обосновано». То есть, им все равно, сколько государственных (наших с вами) денег они вбухают в систему. А вот наличие правильных бумажек им небезразлично.
Эх, есть у меня материал про то, как на законных основаниях обосновать любую стоимость проекта. Только после такой публикации мне нужно становиться Навальным-2 :)
— плохо умеет выражать мысли на русском языке
— ленив или слабо мотивирован
— слабо разбирается в предмете описания
— не владеет всем объемом исходных данных по независящим от него обстоятельствам (например, не подогнали вовремя описываемый модуль)
Когда все пункты выполнены, документация получается отличная. Даже в тисках структуры ГОСТа
По внутренней документации. Даже в нашем маленьком стартапе программисты не могут работать без постановок, которые готовят аналитики. У программистов нет фантазии, им это вообще не нужно. Постановка может содержать уже и Use Case, и эскизы интерфейсов и все, что угодно, чтобы программист понял задачу.
По книжкам. Документация по ГОСТ сделана таким образом, что она может появляться вместе с системой, параллельно. Не думаю, что популярную книжку можно написать до того, как появится предмет описания. А вот потом, глядя на готовую систему и (убогую) документацию к ней, можно уже выдать любой материал для любой аудитории, с картинками и цветными врезками.
Проще всего принять на работу админа начального уровня. Он только в дверь входит, а я уже знаю, подходит чувак или нет :). А вот с другими не так просто.
Во что я твердо верю, это в то, что при желании и ясном представлении цели можно сделать очень многое. Даже безо всяких стандартов. У нас в стране светлые головы еще не перевелись.
По п.2. Часто приходится автоматизировать несуществующие бизнес-процессы. Чтобы опираться хоть на что-то, придумывается некий виртуальный бизнес-процесс, под который пишутся технические документы. Это ненормальная ситуация, но встречается сплошь и рядом. В нашей стране все еще свято верят в то, что с помощью хитрой программы можно решить проблемы бизнеса.
О пользе эскизного проекта я не слышал. Образно говоря, ЭП нужен для изъятия дополнительных дензнаков у заказчика. Вам в итоге можно ограничиться двумя(тремя) документами.
Пишете Пояснительную записку к техпроекту (П2), куда включаете необходимый вам контент в виде разделов по РД50 и руководство пользователя по ГОСТ. Если у вас приложение сложное в обслуживании, сделайте еще Руководство администратора (отдельная книжечка). По сути это просто глава из РП, но так будет проще согласовывать. Заодно там будет минимально необходимый технический контент стадии РД (см. ГОСТ 34.602)
Если заказчик вдруг запаникует и заговорит о ГОСТах, вы раздергаете контент П2 на отдельные «обеспечения» и все будет хорошо.
Так что критика вполне обоснованная. Аудиторию обламывать нехорошо.
У нас принято называть консультантами и тех бедолаг, что настраивают какой-нибудь SAP. Такая же терминологическая путаница, как и со словами «менеджер», который и после курса MBA, и который в магазине к покупателям пристает.
Консультант — это человек, помогающий бизнесу клиента. Поэтому он фигура ритуальная, полумифическая. Он должен соответствовать локальным представлениям об успехе. Если для нас это айфон и паркер, то у него это все должно быть.
К олигарху с айфонами не пойдут, конечно. На том уровне приличному человеку вообще иметь телефон неприлично, когда есть секретарша.
Короче, если то, что задумал MS в Москве это то же самое, что было в Барселоне, 18 тыр нормальная цена. Туда же входят обеды (включая попойку на выставке), пользование всей инфраструктурой и много чего еще.
Лучший праздник для гика, честное слово. Особенно, если вы интересуетесь или работаете с технологиями MS.
Это я все к тому, что не все йогурты одинаково полезны :)
Эх, есть у меня материал про то, как на законных основаниях обосновать любую стоимость проекта. Только после такой публикации мне нужно становиться Навальным-2 :)