Отправляет email-рассылки с помощью сервиса Sendsay

Разработка проектов и управление командой разработчиков

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Больше денег от Вашего бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Январь 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Александр Левитас

Статистика

2.032 подписчиков
-1 за неделю
←   Все выпуски   →

Разработка проектов и управление командой разработчиков


Информационный Канал Subscribe.Ru
---

Предыдущий выпуск закончился на следующем:

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

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

---

Стоп! Пора проанализировать ситуацию.

Два выпуска статей сделаны, готова БД и даже частично готова функциональная спецификация.

НО!

Сейчас припоминаю слова, одного из преподавателей в универе, для которого разрабатывал проекты во время учебы: «люди не всегда догадываются о том, что ты имеешь ввиду, когда рассказываешь о той или иной идее или подходе. Не жмись, и расскажи в деталях и понятным «русским» языком, о чем идет речь»

В РЕЗУЛЬТАТЕ этот совет мне помогал готовить публикации на студенческие конференции. Для тех, кто не знает, что это такое: перед конференцией готовится сборник публикаций и поэтому до того как конференция начнется надо выдавить из себя тезисов на 2 страницы. Ну и приходится брать фразы и расписывать их пока фраза не обрастает десятком предложений, прочитав которые забываешь с чего начал читать и о чем вообще доклад.

Так вот сделав 2 выпуска рассылки, я упустил из виду план разработки. Т.е. он всегда был у меня в голове (в блокноте), но я о нем не говорил.

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

 

План проекта.

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

Я прошел уже пару ступеней, и вот открываю дверь и вижу: к сожалению, вижу только пока я, так как сайт не готов, что есть БД, часть функциональной спек и функциональная спек на сайт.

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

Если же менеджер наберется наглости и спросит разработчика прямо в лицо, а сколько же времени эти рюшечки и бантики займут, то его ожидает что-то типа «ну ты чё не понимаешь что ли, эти же мелочи потребуют 5-10 минут от силы, а красотень-то какая будет!»

Если же менеджер не уймется и будет приставать к разработчику с глупыми вопросами: «а как» и «почему» и «сколько реально времени это потребует», то в итоге откроет для себя и удивленного разработчика, что разработка этой самой рюшечки займет 1-2 дня девелопмента ПЛЮС обсуждения 1-2 дня ПЛЮС 1-2 дня на решение проблем и разбора подводных камней, которых ведь не должно было быть ПЛЮС время на тестирование.

ИТОГ ЯСЕН: включите рюшечки в план, поставьте естимэйшен и посмотрите на сколько вы не вкладываетесь в срок.

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

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

Для тех, кто уже потерял основную мысль – мы о планах проектов.

Мой план проекта на первый релиз таков:

1. разработка интерфейса для добавления профайла кандидата в БД;

1.1 разработка алгоритма  определения дубликатов кандидатов;

2. разработка интерфейса для просмотра профайла кандидата;

3. разработка интерфейса для модификации профайла кандидата;

4. экспорт старой экселевской БД в новую структуру БД;

5. исправление ошибок в новой структуре БД и завершения экспорта старой БД в новую;

ВНИМАНИЕ!!! Уже после пункта 3 система может эксплуатироваться. Однако лучше подождать завершения пункта 5, тогда это исключит ситуацию появления дубликатов кандидатов

6. разработка интерфейса и метода извлечения новых резюме с сайтов рекрутинговых компаний и автоматическое занесение их в БД;

7. подготовка стандартной формы резюме и метода для автоматического занесения заполненной формы резюме в БД

8. тестирование!

После 8 пункта можно закинуть ноги на стол и подождать отзывов от HRM. Просидеть с закинутыми ногами можно пару недель, а потом надо будет править найденные серьезные ошибки для того, что бы все-таки повторно закинуть ноги на стол, но уже со спокойной душой за релиз.

 

Анализ плана проекта  и почему именно эти задачи были включены в первый релиз.

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

Следовательно, пункты 1,2 и 3 плана проекта являются минимально необходимыми для работы приложения (в эти пункты не входит интерфейс для вывода списка кандидатов, потому что он уже описан в спек).

После пунктов 1,2 и 3 можно работать с системой и потихоньку накапливать себе проблемы с появлением дубликатов, когда они неожиданно свалятся на голову после экспорта старой БД (пункт 4 и 5). Поэтому желательно попробовать систему, но для накопления данных не использовать до реализации пунктов 4 и 5.

Комментарий: ничто, конечно, не предотвратит появление дубликатов, но как потом вы увидите, метод определения дубликатов будет работать практически «железобетонно»

Пункты 6 и 7 завершают релиз проекта и можно приступить к полномасштабному тестированию.

Комментарий: тестирование можно и нужно делать во время разработки, но планирование и резервирование времени удобно делать в виде отдельной задачи в плане проекта

После тестирования и запуска в эксплуатацию опять будет анализ change request’ов, плюсов, минусов и планирование исправления найденных не критичных ошибок.

Change request’ы - это не что иное как «фи» клиентов типа «как! У вас нет вот этой функциональности?», «а здесь вот это не работает!», «а это не то что мы хотели L», «а вот это хорошо! но мы хотим, чтобы оно работало по-другому».

Шутка! Благодарность от пользователя – это как медаль команде, даже зарплата уходит на второй план J. Точно вам говорю.

 

Продолжение следует (Что же дальше? Не буду обещать по поводу реализации сайта, но все же он будет готов. Описание новых интерфейсов, проблемы связанные с ними, а так же алгоритмы и подходы будут в следующих статьях)

---

Предыдущие выпуски можно почитать здесь:

Статья 1;

Статья 2.

---

С уважением,

Сергей

prj_management@list.ru

 

 

Subscribe.Ru
Поддержка подписчиков
Другие рассылки этой тематики
Другие рассылки этого автора		 Подписан адрес:
Код этой рассылки: comp.soft.prog.prjmanagement
Архив рассылки		 Отписаться Вебом Почтой
Вспомнить пароль
В избранное