Нить 1.1. Задача про форму заявки. Формирование бонусов в дизайн-студии

2011-07-04 18:06:02

Дмитрий Логинов [log_off@mail.ru] » Сергей В. Сычёв

Ситуация 4. (более сложный случай Ситуации 2)

Разработать сайт на основе существующего в котором было 5 основных разделов, один из них форма заявки.

Требуется:

Видоизменить форму заявки, разместив упрощенный вариант заявки на всех страницах, а сложный - оставить в соответствующем разделе.
Создать 2 вида меню, которое может редактировать Администратор.

Данное решение требует переделки объекта "Форма", а тк же серьезной реструктуризации системы создания структуры сайта.

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

[Показать все ответы на это сообщение]

2011-07-05 21:10:02

Сергей В. Сычёв [sch@triz-ri.ru] » Дмитрий Логинов

Уважаемый Дмитрий!

Видоизменить форму заявки, разместив упрощенный вариант заявки на всех страницах, а сложный - оставить в соответствующем разделе.

Вероятно, это задание дробится на следующие:

1. Создать форму "Упрощенная заявка" - предполагаю, что это задание 1 уровня. (т.к., сложный вариант заявки уже есть и надо создать еще одну форму, отличающуюся меньшим числом полей).

2. Отобразить (объект) форму "Упрощенная заявка" на все страницы.

Т.к., сказано, что "на основе существующего сайта", предполагаю, что

2.1. У объекта "Упрощенная заявка" появится идентификатор (т.к., объект или ссылка на него будет хранится в базе данных).

2.2. В шаблоне страницы уже есть "контейнеры" (места, в которых прорисовывается объект указанный по идентификатору). Т.о., надо выбрать на страницах место для формы "Упрощенная заявка" и должным образом сослаться на объект.

Это тоже задание 1 уровня.

Исключения составляют случаи, когда мы (выбрав должное место на страницах) сталкиваемся с техническими противоречиями.

Варианты (для иллюстрирующего примера):

а) Размеры "Упрощенной заявки" таковы, что, при отображении ее на странице стандартным способом, шаблон исказится. Т.е., нам мешает противоречие: "Размер (параметр, в общем случае) должен иметь одно значение, чтобы ..... , и он же должен иметь другое значение чтобы .... ".

б) Нет места, куда отобразить форму - т.е., нам мешает противоречие: "Здесь должен находиться объект А, но должен здесь же находиться и объект В"

в) ...........

Уважаемый Дмитрий!

Используйте следующее правило всякий раз, когда Вы сталкиваетесь с ситуацией 2-го или 3-го уровня:

шаг 1. Дробите задачу на простейшие (1 уровня) и нормируйте. Когда "не дробится" - к шагу 2.
шаг 2. Когда нормирование становится затруднительным, формулируйте противоречие, которое мешает свести задачу к простейшим. См. выше примеры "а" и "б". (А более развернуто об этом на сквозном примере можно прочитать, например, здесь). Если у Вас нет противоречия, у Вас нет сложной задачи и все легко дробится на задачи 1 уровня. Тогда - возврат к шагу 1. Если будут сформулированы противоречия - к шагу 3.
шаг 3. Т.к., скорее всего в реальной ситуации некоторые задачи попадут на первый уровень, а некоторые будут содержать противоречия, то разделите задачи на разные списки:

список 1 (простейшие 1 уровня, которые легко нормируются, установите им норму);
список 2 - это список технических противоречий

и к шагу 4.

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

Что такое "приемы устранения противоречий", можно позже обсудить. Сейчас я прошу Вас обратить внимание на важный шаг 2: "Если Вы не можете разложить задание на простейшие работы, то письменно сформулируйте, с каким противоречием Вы столкнулись".

Спасибо,

[Показать все ответы на это сообщение]

2011-07-06 18:54:02

Дмитрий Логинов [log_off@mail.ru] » Сергей В. Сычёв

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

Сергей, не согласен с вами.

Для студии не всегда возможно полностью передать работу другому программисту.

Вариант1:

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

Вариант 2.

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

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

[Показать все ответы на это сообщение]

2011-07-07 12:42:02

Сергей В. Сычёв [sch@triz-ri.ru] » Дмитрий Логинов

Уважаемый Дмитрий!

...первый сделал 60% (допустим) работы, а на оставшихся "застрял" и требуется консультация...

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

а) Конкретную задачу, которую первый программист не может решить, следует описать по определенным правилам. Могу привести пример.

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

в) Если сложная задача описана по правилам, то время на консультации по п.б. не считается потерянным. Иначе - см. предыдущее сообщение.

Если п.а игнорировать, то количество обсуждений поглотит все продуктивное время.

Спасибо,

[Показать все ответы на это сообщение]

2011-07-09 19:33:34

Дмитрий Логинов [log_off@mail.ru] » Сергей В. Сычёв

Приведите, пожалуйста, пример, если это вас не затруднит.

Большое спасибо!

[Показать все ответы на это сообщение]

2011-07-11 19:24:23

Сергей В. Сычёв [sch@triz-ri.ru] » Дмитрий Логинов

Уважаемый Дмитрий!

Уточните, пожалуйста, вы привели утверждение, что нужно рассчитывать, что "в месяце 168 рабочих часов (21 рабочий день х 8 часов). Руководитель должен выдать заданий на месяц в этом объеме (лучше чуть больше)", при выдаче заданий. Разве такое где-либо бывает, чтобы сотрудник мог работать 8 часов в день? Как правило, 20% времени теряется (чай, перекуры, туалет и т.п.). Не уверен, что можно требовать большего от среднестатистического сотрудника.

1. Бывает. Например, у нас в компании (и не только у нас) работают гораздо больше. Просто необходим эталон (линейка) = ответ на вопрос, что брать за 1 (единицу) или за 100%. Или что такое "рабочий месяц" для целей учета продуктивного рабочего времени - т.к., астрономические месяцы очень разные (сравните декабрь и январь, например). Так вот, рабочий месяц - это 168 продуктивных часов. Т.е., когда мы говорим, "платим за месяц" - это означает: "платим за качественно выполненный объем работы в 168 нормо-часов". Если у человека производительность выше, то она получается больше 100%. Если меньше - то меньше.

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

2. 20% времени - это 1 час 36 минут (96 мин.) на чай/перекуры/туалет - это у Вас перебор. У Вас 9 человек в группе (в описанном примере) - это 14,4 часов простоя в день или 302,4 часа в месяц.

"Кто любит август", работает и получает от этого удовольствие (и не палит чистый рабочий день в неделю [(96 мин. х 5 рабочих дней)/60 = 8 часов] на перекуры и чай;"кто любит январь", тревожится правильно ли ему учли чай, перекуры, туалет и т.п. Просто не думайте об этом, думайте об этом.

Спасибо,

[Показать все ответы на это сообщение]

2011-07-16 01:36:02

Логинов Дмитрий [log_off@mail.ru] » Сергей В. Сычёв

Уважаемый Сергей!

Пищи для размышлений вы дали много.

Постараюсь внедрить в компании систему нормировки задач для программистов.

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

Спасибо за приведенные примеры - прочищают мозги :-)

P.S.

Насчет перекуров и туалетов - ох, как тяжело дастся такой жесткий учет и нормировка :-)

[Нет ответов на это сообщение]

TRIZ-RI Group

Нужна эффективная схема мотивации менеджеров по закупкам,

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

Авторы

TRIZ-RI Group

Как установить план продаж сотруднику