На сайте ведутся работы 3-я нить обсуждения "Помогите составить систему мотивации для программиста!" | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ

3-я нить обсуждения "Помогите составить систему мотивации для программиста!"

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
2007-11-12 14:47:15
Кирилл Лебедев » Александр

Уважаемый Александр!

Я думаю, что многое прояснится, если Вы приведёте пример возможного описания реального проекта с детализацией  этапы проекта (последовательность работ "от начала и до конца") с заданным шагом, например, в 2 часа.

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

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

Весь проект был разбит на ряд подзадач. Задачи, оценочное и реальное время приведены в таблице:

Задача Оценка (в часах) Затрачено (в часах)
Написать техническое задание

16

16

Провести исследование на тему "Файловые базы данных и хранение графов в файловых базах данных"

24

4

Провести микроисследование по дорожным features и их атрибутам в стандарте GDF 3.0

4

1

Разработать логическую структуру базы данных и интерфейс доступа к данным

4

24

Разработать физическую структуру данных и переработать интерфейс доступа к данным

16

23

Спроектировать реализацию слоя доступа к данным

16

16

Спроектировать тестовую версию простейшего компилятора базы данных для роутинга

16

16

Реализовать слой доступа к данным на C++

8

28

Реализовать простейший компилятор базы данных для роутинга на языке C++

8

20

Протестировать результаты на ПК и КПК

16

16

Итого:

128

166

Из таблицы видно, что слишком оптимистично оценено время, потребовавшееся на реализацию. Тем не менее, время, затраченное на проектирование, оценено практически верно. Суммарная оценка составляла 80 часов. В реальности проектирование заняло 84 часа.

С уважением,

2007-11-12 16:40:19
Александр » Кирилл Лебедев

Здравствуйте, Кирилл!

Спасибо за Ваше участие в обсуждении. Ваше мнение, как видение практика, представляет особую ценность для меня. Насколько я понимаю, в вашем примере речь идёт об относительно  простой разработке, которую можно сравнить с доработкой в рамках очередной итерации большого проекта. Среди стадий Вашей разработки можно выделить "Техническое задание" и  "Рабочий проект". Стадии "Эскизный проект" и "Технический проект" исключены, что, впрочем, допускается стандартами в технически обоснованных случаях. В Вашем примере всё довольно просто - весь проект может быть выполнен в течение 1 календарного месяца и проблемы оценки результативности участников проектной команды в условиях неочевидного результата просто нет. Я же не случайно предлагал привести пример подобного плана для этапа "Разработка Эскизного проекта", т. к. в нашем случае мы решаем зарплатную задачу для участников большого проекта, который может длиться более года.

 

С уважением,

Александр.

2007-11-12 17:28:40
Кирилл Лебедев » Александр

Уважаемый Александр!

Насколько я понимаю, в вашем примере речь идёт об относительно  простой разработке, которую можно сравнить с доработкой в рамках очередной итерации большого проекта. Среди стадий Вашей разработки можно выделить "Техническое задание" и  "Рабочий проект". Стадии "Эскизный проект" и "Технический проект" исключены, что, впрочем, допускается стандартами в технически обоснованных случаях. В Вашем примере всё довольно просто - весь проект может быть выполнен в течение 1 календарного месяца и проблемы оценки результативности участников проектной команды в условиях неочевидного результата просто нет. Я же не случайно предлагал привести пример подобного плана для этапа "Разработка Эскизного проекта", т. к. в нашем случае мы решаем зарплатную задачу для участников большого проекта, который может длиться более года.

 

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

Пример 1. GPS-навигационная система должна предоставлять пользователю такие сервисы:

  • Выполнять поиск координат по адресу.
  • Отображать карту местности и текущее местоположение пользователя на карте.
  • Позволять масштабировать и скроллировать карту.
  • Строить маршрут в заданную точку и/или по заданному пользователем маршрутному плану.
  • И т.д. ...

Каждую из этих задач можно оформить в виде отдельного проекта, для которого нужно ТЗ, дизайн-документ и т.д. и т.п.

Пример 2. Автомобильный роутинг отличается от пешеходного. Если для пешехода требуется наиболее короткий маршрут, то автомобилист может предпочесть быстрый маршрут, т.е. маршрут, которым можно проехать в заданную точку за минимальное время. Кроме того, при поездке на длинные расстояния автомобилист, скорее всего, выберет маршрут, который проходит по автострадам, а не по проселочным дорогам.

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

  • Разработка обычного пешеходного роутинга. Это позволило убедить начальников и заказчиков в том, что компания может разработать модуль роутинга (в этом было сомнение).
  • В готовый модуль был добавлен механизм priority promotion для того, чтобы при роутинге на длинные расстояния алгоритм выбирал автострады.
  • Затем была добавлена оптимизация по времени следования в пути. Т.е. стало возможным строить маршрут оптимальный не только по расстоянию, но и по времени.

Долгое время сделанный таким образом модуль роутинга устраивал всех. Но затем понадобилась КПК-версия. Под КПК маршрут считался слишком долго. Причина заключалась в медленной БД. Было решено сделать для роутинга свою (быструю) БД. Эта переделка вылилась в несколько других проектов:

  • БД и слой доступа к данным для роутинга.
  • Временный компилятор БД для роутинга.
  • Постоянный компилятор БД для роутинга (был создан на основе временного после того, как разработчики убедились, что архитектура временного компилятора такую передлку позволяет).
  • Архивация БД для роутинга и подддержка компрессии и декомпрессии в компиляторе и слое доступа к данным.

С уважением,

2007-11-13 10:37:59
Александр » Кирилл Лебедев

Здравствуйте, Кирилл!

Из Вашего ответа, а также из последнего ответа Сергея Сычёва я делаю вывод о том, что любой этап проекта любой сложности и длительности можно и нужно разбить на шаги длительностью до 2-х часов. При этом должно выдерживаться требование: результат каждого такого шага должен поддаваться количественному и качественному измерению, адекватно отображающему фактически проделанные работы. Под фактически проделанными работами я подразумеваю не те трудозатраты, которые произведены "вхолостую", а только те, которые привели к результату в соответствии с заданием. Проблема заключается в том, что даже промежуточные результаты появляются не в каждый момент времени. Например, мы с Вами заняты решением зарплатной задачи для участников проекта уже намного больше 2-х часов, но решения пока не нашли. Мы написали некоторое количество знаков и сформировали несколько таблиц. С одной стороны, нельзя сказать, что мы нисколько не приблизились к решению, но с другой стороны, в данный момент времени задача не решена и результата ещё нет. Соответственно, если стоит задача оценить нашу результативность именно на данный момент времени, то это оказывается весьма затруднительным. В ответе Сергею я в качестве примера привёл план одного из наших проектов. В нём можно увидеть достаточно много шагов проекта, по которым, на мой взгляд, весьма сложно оценить результат по основному критерию "Результативность по времени реализации проекта". Вобщем-то именно в этом и заключается мой вопрос. Если нам удастся найти на него ответ, то решение зарплатной задачи будет уже "делом техники".

 

С уважением,

Александр.

2007-11-13 14:02:34
Кирилл Лебедев » Александр

Уважаемый Александр!

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

По этой причине и важно создать инструмент, который бы преобразовывал сложную и многофакторную задачу "написать программу" в последовательность четко формализованных шагов с эталонным временем на выполнение каждого шага. Имея такой инструмент, можно всегда оценить, где мы находимся, сколько мы сделали и сколько еще осталось. И, как результат, оценить результативность. Примерами таких инструментов является АРИЗ-85В и Алгоритм "Рекламное Измерение". Есть подобный алгоритм (правда, в черновом варианте) и для программирования. Он уже применяется для проектов продолжительностью от 1-ой недели до 2-х месяцев. Что касается больших проектов (длительностью год и более), то, как я уже писал выше, они легко разбиваются на небольшие проекты.

С уважением,

2007-11-13 16:05:41
Александр » Кирилл Лебедев

ОК.

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

С уважением,

Александр.

2007-11-13 17:07:36
Кирилл Лебедев » Александр

Уважаемый Александр!

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

Пожалуйста, перечислите основные и вспомогательные полезные функции разрабатываемой программы вообще и эскизного проекта в частности:

  • Программа должна выполнять:
    • главную полезную функцию,
    • вспомогательную полезную функцию 1,
    • вспомогательную полезную функцию 2,
    • ..................................................................
    • вспомогательную полезную функцию N.
  • Эскизный проект должен выполнять:
    • главную полезную функцию,
    • вспомогательную полезную функцию 1,
    • .................................................................
    • вспомогательную полезную функцию M.

С уважением,

2007-11-13 18:02:17
Александр » Кирилл Лебедев

Здравствуйте, Кирилл!

Редакция разделила наше обсуждение на разные ветви, за что ей отдельное "спасибо". Я обязательно буду продолжать обсуждение по обеим ветвям, но в данный момент мне кажется, что Ваше последнее сообщение и сообщение Сергея Сычёва по сути требуют одного и того же ответа. Если Вы согласны, то я планирую дать ответ в параллельной ветви. Если потребуются какие-либо дополнительные разъяснения, пожалуйста, дайте знать.

 

С уважением,

Александр.

2007-11-14 12:14:21
Кирилл Лебедев » Александр

Уважаемый Александр!

Если Вы согласны, то я планирую дать ответ в параллельной ветви. Если потребуются какие-либо дополнительные разъяснения, пожалуйста, дайте знать.

Хорошо!

С уважением,



Яндекс.Метрика