Поздравления из Таллинна

Всегда ли чем быстрее тем лучше?

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

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

Кроме того, решение, что проект может быть закончен быстрее на более или менее раннем этапе означает, что у вас больше нет этого времени для дальнейшего улучшения проекта, особенно если новые сроки были оглашены для директоров. Хотя данное описание кажется элементраным и естественным: «решили, что надо меньше времени» – «меньше времени имеем» оно не столь очевидно для многих из-за простоты урезания сроков. Многим кажется, что убавить сроки разработки и увеличить – всё это одинаково легко. Как правило убавить легко, так как с радостью воспринимается менаджементом, а вот прибавить воспринимается с недовольством, так что «что с возу упало, то пропало».

Типичным явлением после уменьшение сроков является:
1. Попытка менаджемента добавить функциональность по требованиям клиентов на достаточно позднем этапе
2. Обнаружение серьёзных неточётов – мой опыт показывает, что вероятность возникновение данной проблемы 200%, т.е. мало того, что они возникнут гарантировано, так ещё и не одна. Проблемами могут быть логические несогласованности функциональностей либо технической инфраструктуры, проблемы с производительностью итд.

Более того, самым опасным здесь является тот факт, что в результате разнообразные надстройки/подпорки в коде будут использованы чтобы решить проблему. Как правило такие решение принимаются с лёгкостью ибо все убеждены – исправим в следующей версии. Реальность такова, что в следующей версии будут более высокоприоритетные задачи – «ибо тут и так рабатоет, да и дополнительное тестирование понадобиться – так что давайте оставим». Особенно если никто из клиентов не жалуется на данный участок функциональности. В результате производства всех этих подпорок, вы получите код который будет очень и очень сложно продолжать и будете строить «workaround» (обходной код) вокруг существующего обходного кода и так до бесконечности, пока разрабочики не плюнут и не уйдут в другую фирму (чтобы там столкнуться с таким же кодом :) ). Поэтому ни в коем случае не полагайтесь на «потом исправим» - постарайтесь сделать нормально сразу, а чтобы было достаточно времени, подумайте трижды урезая свои ресурсы.

И естественно учитывайте, что чем больше вы работаете над функциональностью, чем лучше вы видите возможности сделать всё «идеально», и соответственно оставьте себе время на переработку кода под конец проекта.

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

Наконец, давайте рассмотрим неопределённости, которые сушествуют в льбом проекте. Даже для методов с коротким циклом, таких как «agile» или просто итеративных, вероятно, что приоритеты внутри проекта будут переопределены добавляя или убирая ту или иную функциональность.

Таким образом я крайне не рекомендуют поспещные решения в урезании сроков проекта ибо быстрее не всегда лучше, особенно если вы не оценили всех факторов влияющих на конечные сроки.

H-индекс для вычисления производительности учёного

Продолжая тему о индексировании, ссылках и эффективности работы учёного.

В билиотечном деле известен такой индекс как h-index для более эффективного измерения вклада человека в науку нежели просто количество работ или ссылок. Данный метод является комбинораванной мерой включая как производительность (количество статей) так и их влияние (количество ссылок) учёного. Он расчитывается как: количество статей каждая из которых имеет ссылок не менее этого количества статей. Иными словами, например, чтобы получить индекс 5 у человека должно быть не менее 5 статей на каждую из которых есть не менее 5 ссылок. Индексу 6 будет соответствовать случай, когда имеется не менее 6 статей имеющих (каждая) по 6 или более ссылок и так далее.

Изобретателем данного индекса явлается Jorge E. Hirsch. Он же определил что
1. данный индекс хорошо покаывает вероятность получение Нобелевской премии
2. определяет следующую градацию - если у кого-то имеется индекс 10-12, то университет должен серьёзно рассмотреть его кандидатуру к принятию на постоянную работу. Если индекс 18, то уровень человека соответсвует полному профессорскому званию, а с 45 он может рассчитывать на членство в Американской академии наук (т.е. быть академиком).

Положительные и отричательные стороны данного метода вы можете сами прочитать в Wikipedia

Само-архивирование

Одной из оценок эффективности деятельности учёного является количество ссылок которые он получает от других учёных.

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

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

Для разрешения данного конфликта появилось 2 метода. Во первых работы могут быть опубликованы через специальные, публичные журналы, которые всё ещё осуществляют процесс рецензирования. Их не так много, но они есть и мы можем сравнить их с програмным обеспечением с открытым кодом.

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

Любой автор ОБЯЗАН использовать данную возможность для увеличения заметности своей работы и как следствия увеличения вероятности использования данной работы другими авторами для дальнейшего развития и как следствие зарабатывая таким образом ссылки на свои работы. В конечном итоге работа пишется не для себя, а для всего мира!

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

Сжатие; Взаимодействие vs Сотрудничество

Продолжая читать дипломную работу"Towards an Integrated Approach to Collaborative Web Usage" нашёл ещё два интересных описания/определения.

Сжатие
Функция которая позволит работать с поделементами длинного документа (и кроме того определить какие из них представляют для него наибольший интерес) – при сжатии внутри документа ищутся секции и под-секции ориентируясь на соответствующие тэги (H1, H2, итд.). Затем у пользователю появляется возможность свернуть или развернуть эти секции (collapse / expand)

Взаимодействие vs Сотрудничество / Collaboration vs Cooperation
Сотрудничество (collaboration) процесс при котором несколько людей работают для достижения общей цели. Например группа учённых работающих в одной отрасли и обменивающаяся результатами исследований. Хотя этот процесс некоторые называют взаимодействием отношение между вовлечёнными сторонами значительно более сильное. К примеру взаимодействовать могут конкуренты тогда как при сотрудничестве уровень доверия и обмена информацией значительно выше. Кроме того при сотрудничество появляется «команда» ([Maxwell, Beyond Cooperation]). Поэтому два конкурента могут взаимодействовать, например разрабатывая новый стандард который необходим им обоим, но это не будет означать сотрудничества.

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