?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06
Tags: , ,
И самое интересное - стоит сказать про "документацию" правду, которую в глубине души и так все знают, - и это обычно провоцирует бурление говн, и поток самых невероятных высказываний.

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

MoreCollapse )

Comments:


Page 2 of 2
<<[1] [2] >>
Pavel Egorov
xoposhiy at 2011-06-23 09:28 (UTC) (Link)
Вот ещё одна причина в копилку:
Написать устройство сложной штуки, чтобы его почитали другие и выявили проблемы, например, ещё до написания кода. Или, например, потому что не получается организовать код также удобно для чтения как текст.
chmelvv at 2011-06-25 17:48 (UTC) (Link)
Недобрый день!
Впервые зашел на ваш блог.
По сути топиков видно, что вы человек дела и воды не льете. Это классно!
Но меня удивило огромное количество мата. Это типа кул?
К чему оно? Кроме раздражения ничего не вызывает.
Чесно говоря, просто физически хочется пойти помыться ...
Gaperton
gaperton at 2011-06-26 15:22 (UTC) (Link)
В следующий раз забаню за оффтоп.
Gaperton
gaperton at 2011-06-26 15:28 (UTC) (Link)
И за попытку перевести разговор на личности. Достаточно еще одного подобного комментария.
valerkar at 2011-08-25 04:56 (UTC) (Link)
подпишусь под каждым словом. Единственно что - договор - достаточно в широком смысле может трактоваться - у нас обычно необходимость в документации возникала только при общении с заказчиком, с двумя основными целями - зафиксировать scope проекта, согласовать интерфейсы для интеграции. В разработке,и суппорте особенно - issue tracker (TFS) с возможность ассоциировать чекины с задачами - вещь бесценная для суппортера. И что-то wiki - продобное для храниния урлов, логинов, спецификаций. А с "учебниками" у нас было как-то не очень.
Ласка
wesel at 2012-02-25 15:47 (UTC) (Link)
Прошу прощения за комментарий в довольно старом посте, и тем не менее, хочу задать один вопрос.

Как Вы решаете проблему масштабируемости процесса передачи знаний о работе программы? Предположим, есть архитектор, который знает, как все работает. Есть некоторое количество внедрений и клиентов, которые генерируют запросы - не нравится то, не нравится это, хотим вот такую фичу, не понимаем, как работает вот это, не знаем, как поступать в такой ситуации. Есть некоторое количество внедренцев, которые с клиентами общаются. Архитектор\программисты будут консультировать каждого из них? По мере появления вопросов? А когда они будут кодить, в рабочей неделе всего 40 часов? (:
Gaperton
gaperton at 2012-02-28 12:37 (UTC) (Link)
При большом количестве обращений внедренцев, которое наблюдается в моменте - внедренцы собираются вместе, и для них проводится организованное обучение - набор лекций/семинаров. Это сразу снижает количество обращений.

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

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

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

И все. В зависимости от характера работы внедренцев, может оказаться целесообразным вести для них документацию по типовым случаям, или "справочники". А может и нет - описываемая мной схема во многих случаях делает возможным ненапряжную передачу знаний и без документов.
Ласка
wesel at 2012-02-28 13:00 (UTC) (Link)
А Вы не могли бы в двух словах охарактеризовать, какой по смыслу продукт Вы таким образом внедряете?

Я поясню мысль. Мы работаем над системой автоматизации ВУЗа - это порядка десятка модулей, с которыми работают люди с разных подразделений, вводя и используя кучу разных, но связанных между собой данных.

И тут возникает проблема. Когда клиент задает вопрос "как нам ввести наши данные в вашем блоке А", мы должны просчитать последствия возможных вариантов в блоках B, C, D, E, задать клиенту уточняющие вопросы о том, как данные в них должны затем интерпретироваться, а затем предоставить ему на выбор варианты, опять же разъяснив, как ситуация в зависимости от его выбора будет развиваться в дальнейшем.

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

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

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

При этом у нас не бывает большого количества однотипных обращений. Число внедрений относительно невысоко, но зато все вопросы специфичны для ВУЗа, и, как мне кажется, закрыты обучением быть не могут - как правило, вопросы возникают в ситуациях, когда процесс работы с данными у клиента отличается от того, что мы видели и предусматривали раньше.
Previous Entry  Next Entry