на почитать - статья Владислава Балина - "Оценка трудозатрат по разработке ПО"

http://gaperton.livejournal.com/34265.html

Техсаппорт для аналитиков

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

Так вот - это неприятно :). Пользователи используют систему не так, как ты придумал, хотя ты со всеми общался и требования вроде собирал. Все делают по другому. Наступают на глупые какие-то грабли, которые тебе граблями не кажутся. Тратят на это кучу своего и твоего времени.

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

Отсюда вывод - или аналитиков (product manager-ов) иногда нужно ссылать на поддержку продукта, который они создали, причем на самую неблагодарную ее часть - решение мелких бытовых вопросов пользователя, либо аналитики должны сами органиовывать получение feedback информации от саппортеров. Обязательно. Иначе так и будут витать в облаках ;)

Про рабочие обязанности, проактивность и миро-творчество

Подумалось тут о рабочих обязанностях

Те обязанности, которые привязаны к функциональным ролям (разработчика, аналитика, менеджера) и соответственно через это к конкретному сотруднику - это _минимум_ того, что он может/должен на себя принять.
Чтобы работа спорилась, а результаты ее становились все лучше и лучше, нужно брать на себя новые обязанности. Хотя бы для саморазвития.

Конечно, есть и ограничения. Куда же без ограничений:

• Задачи должны быть интересными. Ну например, я разработчик но хочу поучиться юзабилити - отличный повод попробовать в свободное время порисовать интерфейсы и попредлагать их команде.
• Взятые обязанности не должны мешать текущим. Как минимум, не отнимать (ну разве что совсем чуть-чуть) времени, которое надо бы тратить на выполнение своей основной работы. Отнимать чуть-чуть времени, это кстати круто. Это запускает действие витамина разнообразия...
• Нельзя изменять рабочий процесс. Опасно, конда другие участники команды принимают то, что ты выполняешь какие-то новые обязанности, как данность и забывают о том, как "должно быть". То есть если ты рисуешь интерфейсы "для души" - то отдавай их человеку, который отвечает за проектирование UI. И уж конечно, держи его в курсе всех своих идей, не оставляй за бортом. И только от него принимай задачи, если уж таковые для тебя найдутся. А остальные члены команды должны по-прежнему взаимодействовать на предмет UI с тем человеком, которому этот UI поручен.

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

Так вот и меняется этот мир, приспосабливаясь к нашей воле :-)

Обсуждение на RSDN - "Как найти и удержать программиста"

http://www.rsdn.ru/forum/message/2628646.aspx

"Столкнулся с ситуацией — приходит человек на работу, работает какое-то время, потом уходит, мотивируя тем, что работа ведется не по классическим технологиям, техзадания неконкретные, код не по Макконелу, архитектура не по паттернам проектирования и вообще, мол, хочу в крупную компанию.

Да, действительно, мы не используем в работе никакой из современный методологий разработки ПО; да, формализация задач слабая; да, работа не вполне регламентирована и упорядочена. Но надо же четко понимать, что москва не сразу строилась и все такое. Любая компания начинала с комнатки в нии и два разработчика за пыльным столом...."

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

Использую, но не люблю

Понял, чем не нравятся скринкасты - их нельзя читать по-диагонали. Отсюда - тратится больше времени.

Хотя в работе скринкасты использую постоянно - вместо того, чтобы потратить 2 часа на написание документа, можно за 10 минут сделать скринкаст.

Какие бывают методологии

1. Хорошая статья на RSDN: http://rsdn.ru/article/Methodologies/SoftwareDevelopmentProcesses.xml
2. Мое исследование про выбор (точнее, попытку выбора) основы для методологии разработки RapidSoft

Eclipse Process Framework Composer

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

Чувствую, в ворде процессы я больше описывать не буду :-)


Ссылки
* http://www.eclipse.org/epf/
* http://www.aprocessgroup.com/products/tool_03_0301.asp