Мысль о Research Reports

Мысль навеяна воспоминаем одного друга о прошлой работе и кое какими событиями на текущей...

Вопрос

Насколько эффективно выполняются research задачи?

Небольшое пояснение

Оставим случаи 'пойди туда, не знаю куда', а рассмотрим какую нибудь простенькую задачку, с внятной целью.
Ну например: 'научится маппить связь один-многие в Hibernate'.
Под эффективностью я имею ввиду не численный показатель, а меня интересует вот что:
Допустим задание было дано человеку, который не знает что такое 'связь один-многие'. Этот самый человек скорее всего сделает следующее:

• сначала почитает что такое one-to-many, заодно и все остальные виды связей;
• потом он найдет документацию, и прочитает какую аннотацию поставить или что прописать в файл маппинга;
• затем (если по хорошему) он попробует сделать небольной примерчик, а может даже найдет какой нить hibernate tutorial.

В итоге мы получаем 3 момента:

• человек потратил примерно день на исследование;
• формально, результатом этого исследования является всего лишь одна строка кода (аннотация)
• все остальные добытые знания, в лучшем случае останутся в голове у исследователя

Есть еще неявный четвертый пункт - если этого человека не будет 'под рукой', а понадобится, ну скажем замаппить many-to-many, в этом случае второй 'исследователь №2' проделает почти такой же путь.

Что не нравится

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

'Что же делать?' или 'Причем здесь друг со своей прошлой работой?'

Так вот, на прошлой работе друга, разработчиков заставляли писать 'Research Reports'.
Подробностей я не знаю, но родилась мысля: а что если такой отчет будет содержать следующие пункты:

• Цель
• Найденные ресурсы
• Выводы
• Размышления и рекомендации

Пару слов в защиту бюрократии :)

Итак, отчеты мы писать не любим, восновном по тому, что:
а) это нам не нужно (кажется бесполезным делом)
б) это занимает время. И если приходится заниматься малоинтересным делом (см. пункт А), то кажется что времени это занимает ну оооочень много.
Так вот, по поводу 'полезно/бесполезно':

• этот отчет может пригодится самому исследователю, т.к. содержит кучу ссылок
• этот отчет может пригодиться коллегам
• этим отчетом можно 'отмазаться' от долгих расспросов 'а как? а зачем? а почему?':)

По поводу времени: если его заполнять 'по ходу', то накладных расходов на ведение отчета будет совсем не много. Например: во время целевого поиска чего либо в интернете (ну например, какую камеру купить? или как чего нить настроить?), как правило открывается куча страниц. Чтобы по ходу сохранять 'стоящие' закладки, требуется совсем не много времени (время на нажатие Cntr+B).
'Размышления и рекомендации': если по ходу делать заметки, типа 'URL-доступно рассказано про стратегии маппинга отношений ; URL-толковый Hibernate tutorial' и т.д., то в этом случае 'польза от исследования' будет значительно больше чем просто одна аннотация.
По поводу цели два момента:
1. Если не удается внятно сформулировать цель, то решать задачу бессмысленно
2. Если есть конкретная цель, то будет меньше поводов 'свернуть в дремучий лес'. Ну например, начать с маппинга отношений, обратить внимание на теорию реляционных БД и закончить Oracle - two days DBA.

Выводы

К сожалению, такие простые вещи как Research Reports как правило не делаются. И многие 'поисково-исследовательские' задачи начинаются без четкого понимания, что и для чего нужно нужно. Как правило, результаты в очень скудных порциях 'оседают' в коде, блогах и головах исследователей. А из этих самых голов, знания улетучиваются в течении 2-3 мес.
Так вот и получается, что как правило решение эти задач весьма не эффективно, и повторить такое решение, ну скажем, через пол года оказывается довольно проблематично.