Отправляет 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
---

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

Сайт Готов! Ура!

Самый замечательный дизайнер Оля смогла выделить кусочек времени и подготовить первый драфт сайта о проекте «База Данных Кандидатов»: http://onlive.nm.ru/softwareonlive/candidatedb/about_project.html

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

---

Проблемы. Мозговой штурм

Приступил к разработке формы для добавления кандидата.

Взял за основу форму резюме (форма резюме содержит около 30-40 полей, а то и больше) плюс дополнительные поля, которые нужны менеджеру по кадрам (такие как ссылки на анкеты, комментарии, статус и подобные им).

В результате форма для добавления кандидата получилась огромной. Все поля вот они! Но только от одного ее вида заполнять ее ну ни в какую не хочется.

Однако первый шаг в разработке этой формы есть, кривой, но все же.

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

В проектировании проекта такое часто встречается. К примеру, надо разработать форму, которая должна быть функциональной, удобной, простой и user-friendly.

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

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

Теперь по поводу того, откуда такая гигантская форма более чем на 40 полей появилась, зачем она и почему такая гигантская.

Начну с назначения – оно очевидно. Форма добавления служит для добавления :), т.е. что бы кто-нибудь появился в БД, то его надо туда добавить. Добавить можно конечно и автоматически (к примеру, методом автоматического извлечения кандидатов из веба) или в ручную, если информация о кандидате приходит по почте или кандидат звонит нам.

Т.е. ручной способ добавления нужен.

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

Все вроде честно. Нужна форма – получи и распишись.

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

И вот после такого цикла «сделал – отдал – недовольны» и начинается второй шаг. Его обожают аналитики и проектировщики (т.е. «ленивые» разработчики), так как работать надо больше головой, а не руками.

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

Разработка первой версии формы добавления кандидата была нудной – попробуй-ка добавить все 40 полей и описать их характеристики и поведение на форме. Никакого тебе творчества и изобретательства. Голова задействована только на уровне глаз, и за нее отдуваются руки.

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

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

Тут даже к гадалке не ходи. И так было понятно, что 80% полей не будут использоваться в этом режиме НИКОГДА!

Отвечаю на собственный вопрос по поводу слова «НИКОГДА».

Комментарий: я начал с проблемы количества полей на форме, потому что сам не люблю формы, на которых куча контролов, а в 90% случаев мне надо заполнять только некоторую часть этих полей  

Так вот, что бы ответить на вопрос «почему НИКОГДА», надо задуматься, а в какой ситуации кандидат добавляется вручную в БД. (Чтобы люди думали, что вы задумались надо отвести глаза в левый верхний угол, если в правый верхний – то значит хитрим. Это так из области психологии, что бы расслабиться)

Ниже результат обдумывания (так как выпуск идет в текстовом формате тоже, то вместо таблиц буду приводить списки):

- получение инфо о кандидате из веба – 70%;

- получение инфо о кандидате по почте – 20%;

- получение инфо о кандидате по телефону –5%;

- получение инфо о кандидате из газет – 3.5%;

- получение инфо о кандидате через знакомых – 1%;

- получение инфо о кандидате из других источников – 0.5%.

У вас значения могут быть другими, но у меня вот так получается. Ну что же – все видно! Правда?

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

1) Те, кому хватило времени, сил и смелости выдавить из себя «здравствуйте» и «что у вас за работа», а после разговора ни ответа, ни привета;

2) Те, кто не только поздоровался и поинтересовался о вакансии, но и спросил, как поживаем и какие у нас цены. Но затем опять исчез с провода;

3) Те, кто не остановился на «жизни» и спросил «что дальше?» - наш кандидат!

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

- Дата получения: все источники;

- Фамилия: -

- Имя: веб, телефон, знакомые;

- E-Mail: веб, почта, газеты;

- Телефон: веб, почта, телефон, газеты;

- Позиция (программист, ...): все источники

- Языки программирования: веб, почта, телефон, газеты;

- БД: веб, почта, газеты;

- Операционные системы: веб, почта;

- Причина поиска работы: телефон;

- Аттач резюме: веб, почта;

- Статус обработки кандидата: самое нужное поле :).

Далее подсчитываем какие поля больше всего использовались – их в верх формы, остальные либо в низ формы либо в сад.

Вот такая вот получилась форма (на момент чтения этой статьи спецификация еще может быть не выложена в инет для скачивания).

Перед тем как сказать, что будет в новых выпусках, воспользуюсь преимуществом рассылки, что бы сообщить, что ищу достойных людей + программистов :) на php, Perl, C# (C# - особо актуально!) и базавиков MS SQL + Oracle. А так же у нас есть вакансии тестировщиков (желательно со знание автоматических тулзов), эксперта по юзабилити и технического писателя.

О да! Моя фирма находится в Минске, так что преимущественно рассматриваем тех, кто может работать в «тесном контакте» с нашей командой, однако возможны и исключения (в плане удаленной работы).

Ну, все, счастливо!

В следующих выпусках: алгоритмы и новые формы. Новые проблемы и их решения. :)

---

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

---

С уважением,

Сергей

prj_management@list.ru

 

 

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