[izuware]

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

Очень характерная проблема - что ответственные меня тупо не понимают. То ли я слишком много говорю, то ли говорю не то что нужно, но регулярно натыкаюсь на то, что сути до ответственного мне донести не удается. Как человек будет делать задачу, сути которой он не понял? Сказать о том, что они не поняли они, грубо говоря стесняются. В итоге делают те задачи, которые понимают и так как понимают. Тоже хорошо конечно - но это как правило отработанные процедуры (часто еще и тупиковые). Есть еще классическая проблема текучки, когда 70% времени отъедают мелкие, но важные (вроде бы) вопросы, а в оставшееся время ничего крупного не засунешь сугубо из-за неудачной скважности.

 

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

[Прохожий]

Описать процесс можно так:

Цель: ответ на вопрос "ЗАЧЕМ?"

План (стратегия): ответ на вопрос "ЧТО ДЕЛАТЬ?"

Тактика: ответ на вопрос "КАК ДЕЛАТЬ?"

А есть еще оперативное искусство :)

 

Вы тут так феерично перевираете военную систему управления, что я искренне и долго поржал :)

 

и как оценивать программиста-разработчика?

А что ты хочешь, чтобы он делал? ;)

 

Допустим идет великая отечественная война. А ты например, комбат. Сидишь в каких-то окопах, тебя как-то бомбят, ты как-то отстреливаешься. Иногда идешь на какую-нибудь высоту. Иногда тебя откуда-нибудь выбивают. Но ты знаешь, только то, что видишь собственными глазами и слышишь ушами. Можно так воевать? Ну в общем-то да. Но... будет как-то тупо.

На самом деле у КОМандираБАТальона в каждый конкретный момент времени есть понятная боевая задача. Наступление ли, оборона ли - всегда задача ему сверху сформулирована. А то, что ты описал - это партизанский отряд. Может быть в этом вся причина? ;)

[kapa]

Вы тут так феерично перевираете военную систему управления, что я искренне и долго поржал :)

Я вот тоже решил не поддерживать аналогию :)

 

 

и как оценивать программиста-разработчика?

А что ты хочешь, чтобы он делал? ;)

Понятно что - программировал и разрабатывал :))

[wanderer_from]

Вы тут так феерично перевираете военную систему управления, что я искренне и долго поржал :)

ну уж и не поиграть :)

[G.K.]

 

и как оценивать программиста-разработчика?

А что ты хочешь, чтобы он делал? ;)

Понятно что - программировал и разрабатывал :))

 

"как оценить работу программиста-разработчика?"

 

Практически - вы все ничего не понимаете в настоящем искусстве! Я - Художник!!! Я так вижу!

:)

Изменено 16 августа, 2012 пользователем G.K.

[micho]

Ну я не знаю как оценивать труд программиста-разработчика, а от труд программиста разработчика под 1С оценивается достаточно просто: сделал или не сделал. Соответственно заплатили или нет. Бывает еще сделал но не то что ожидалось - тут уже идут разборки с бухгалтерией о точности формулировок. Разве в случае прикладного или системного программирования архитектор не должен формулировать задачу, а потом оценивать ее выполнение, как это делает главбух в случае 1С?

[Danuuk]

Считаю полезным показать структуру управления процессом разработки ПО, что использует один "знакомый".

 

"ИМХО право на "творчество" в проекте имеют только ведущие разрабы, архитекторы, тимлиды и т.п.. кодерам, техдизайнерам, копирайтерам и т.п. творчество противопоказано. Максимум расширить рамки.

 

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

 

Для того, что бы кодеры не умирали от быдлоработы сделаны простые вещи:

нет четкой системы кто что должен сделать, так как у задачи есть 2 показателя: цена и срок

срок — это скрытая переменная, она используется для формирования облака задач.

цена задачи — это её цена в рублях/попугаях (у нас тупо рубли)

 

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

например если накодил на 10 тыс, то получишь 14

накодил на 20 — получи 30

 

что из себя представляет система вся для работника:

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

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

есть система сообщений в задаче для обсуждения + общая болталка

 

для ведущего разраба:

он задает все задачи + выстраивает последовательность их выполнения (группами или поштучно)

его задача состоит и в том, что бы принимать выполненные задачи, интегрировать их в проект (90% автоматом делается).

 

в паре с разрабом сидит тех. писатель. у него 2 задачи. формулировать правильные описания + по принятым задачам постить в вики проекта (потом их нее документация собирается)

 

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

 

вся цепочка растянута на 2 недели так как:

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

 

есть суперплюс во всей схеме:

кодеры могут быть фрилансерами которых можно набрать пачками.

общий код не утекает на сторону (за некоторые модули личной жопой отвечаю)

Общий уровень знаний для кодеров занижается, что снижает цену

нет проблем с кадрами, ща их всего в системе более 500 зарегано, активных не более 70, самая основа — это 43 человека сейчас.

 

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

 

ПМ видит проект как диаграмму ганта, которая больше напоминает экран дефрагментатора. зеленый квадрат — готовый тикет, красный — не готово, оранжевый — в работе и т.д. зависимые группы как в ганте на новых строках.

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

[Прохожий]

Понятно что - программировал и разрабатывал :))

Вот Вам и ответ. Он сидит, программирует и разрабатывает. Ваши жалобы на отсутствие результата - мимо кассы, в вашей системе результата нет ;)

 

Считаю полезным показать структуру управления процессом разработки ПО, что использует один "знакомый".

Респект, умно и грамотно организованный бизнес :)

 

Такого человека на любой проект исполнительным директором можно брать влет. За почти любые деньги в пределах разумного :)

[kapa]

Понятно что - программировал и разрабатывал :))

Вот Вам и ответ. Он сидит, программирует и разрабатывает. Ваши жалобы на отсутствие результата - мимо кассы, в вашей системе результата нет ;)

У меня не было жалоб. У меня был интерес к расшифровке этой "мудрости" применительно к конкретной позиции:

"Скажи мне, как ты меня будешь оценивать, и я скажу что я буду делать" (с) управленческая мудрость

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

[kapa]

Разве в случае прикладного или системного программирования архитектор не должен формулировать задачу, а потом оценивать ее выполнение, как это делает главбух в случае 1С?

А оценивать в чём и как?

По соответствию исходным требованиям? А если всплывают нюансы по ходу разработки, то их как учитывает?

По количеству строк кода? По срокам? А кто определяет это изначально? Основываясь на чём?

[micho]

kapa

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

[Прохожий]

А если всплывают нюансы по ходу разработки, то их как учитывает?

Что значит "всплывают нюансы"?

Парадокс в том, что если софт ПРОЕКТИРУЕТСЯ, то в итоге он достаточно отчетливо дробится на внятно описанные модули и классы, которые просто надо делать.

 

Другой вопрос, если софт просто берется и пишется. По велению сердца. Тогда, конечно, да :)

[G.K.]

Разве в случае прикладного или системного программирования архитектор не должен формулировать задачу, а потом оценивать ее выполнение, как это делает главбух в случае 1С?

А оценивать в чём и как?

По соответствию исходным требованиям? А если всплывают нюансы по ходу разработки, то их как учитывает?

По количеству строк кода? По срокам? А кто определяет это изначально? Основываясь на чём?

 

Оценивайте в деньгах :)

универсальный эквивалент.

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

И вообще, что вы всё - как оценивать, как оценивать? если человек работает ровно, без косяков, с текущими задачами справляется, зачем его вообще оценивать?

Мне ближе такая система оценки: справился - не справился.

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

[kapa]

А если всплывают нюансы по ходу разработки, то их как учитывает?

Что значит "всплывают нюансы"?

Парадокс в том, что если софт ПРОЕКТИРУЕТСЯ, то в итоге он достаточно отчетливо дробится на внятно описанные модули и классы, которые просто надо делать.

Если софт пишется для проекта, то да. А если для людей, то иногда может в итоге выйти не совсем то, что было изначально спроектировано. Т.к. пока те, кто будет им пользоваться, не начнут тыкать мышкой и осуществлять обратную связь, чего-то полезного может и не получиться.

[micho]

Прохожий

ну есть еще такие вещи как неожиданные баги в системе или в API. Так что нюансы бывают. Они, кстати бывают и известные, но проектировщик омжет не быть досттаточно эрудированным.

[kapa]

Разве в случае прикладного или системного программирования архитектор не должен формулировать задачу, а потом оценивать ее выполнение, как это делает главбух в случае 1С?

А оценивать в чём и как?

По соответствию исходным требованиям? А если всплывают нюансы по ходу разработки, то их как учитывает?

По количеству строк кода? По срокам? А кто определяет это изначально? Основываясь на чём?

 

Оценивайте в деньгах :)

универсальный эквивалент.

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

И вообще, что вы всё - как оценивать, как оценивать? если человек работает ровно, без косяков, с текущими задачами справляется, зачем его вообще оценивать?

Мне ближе такая система оценки: справился - не справился.

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

Это не ко мне - это к Прохожему. Его "мудрость" была.

[Прохожий]

И вообще, что вы всё - как оценивать, как оценивать? если человек работает ровно, без косяков, с текущими задачами справляется, зачем его вообще оценивать?

Оксюморон, не так ли?

 

Мне ближе такая система оценки: справился - не справился.

Дык, любая система оценки сводится именно к этому. Без вариантов. Вопрос только, что есть "справился" ;) И в этом вся сложность.

 

ну есть еще такие вещи как неожиданные баги в системе или в API. Так что нюансы бывают. Они, кстати бывают и известные, но проектировщик омжет не быть досттаточно эрудированным.

Ой, а сколько нюансов в других областях проектного управления! Причем - недокументированных. Фура с оборудованием перевернулась. Бригада запила. Здание сгорело ;) Вопрос не в этом, а в том, какие действия предпринимает человек, встретив "нюанс")))

[kapa]

Прохожий, там не мои цитаты

[Прохожий]

Извини, есть такая бага, когда выделяешь в одном сообщении, а кнопку "цитата" выбираешь в другом :)

[G.K.]

 

Дык, любая система оценки сводится именно к этому. Без вариантов. Вопрос только, что есть "справился" ;) И в этом вся сложность.

 

Никакой сложности. "Справился", это когда к человеку (касаемо выполняемой им работы) ни вопросов, ни претензий нет.

[micho]

Ой, а сколько нюансов в других областях проектного управления! Причем - недокументированных. Фура с оборудованием перевернулась. Бригада запила. Здание сгорело ;) Вопрос не в этом, а в том, какие действия предпринимает человек, встретив "нюанс")))

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

[izuware]

Никакой сложности. "Справился", это когда к человеку (касаемо выполняемой им работы) ни вопросов, ни претензий нет.

только надо потратить время и доказать что "это" не относится к выполняемой работе.

[Прохожий]

"Справился", это когда к человеку (касаемо выполняемой им работы) ни вопросов, ни претензий нет.

А вопросы и претензии всегда объективны и обоснованы? ;)

 

Еще раз вернитесь к моей сентенции и поймите где причина, а где следствие. Если Ваша практика такова - то Вы ровно это и получите: отсутствие вопросов и претензий у одного человека к другому. Т.е. Вы просто постулируете абсолютно субъективную оценку. Ну вот и все. Задача работника - добиться, чтобы начальник оценил его положительно. Любым способом.

 

Такие дела.

[G.K.]

"Справился", это когда к человеку (касаемо выполняемой им работы) ни вопросов, ни претензий нет.

А вопросы и претензии всегда объективны и обоснованы? ;)

 

Еще раз вернитесь к моей сентенции и поймите где причина, а где следствие. Если Ваша практика такова - то Вы ровно это и получите: отсутствие вопросов и претензий у одного человека к другому. Т.е. Вы просто постулируете абсолютно субъективную оценку. Ну вот и все. Задача работника - добиться, чтобы начальник оценил его положительно. Любым способом.

 

Такие дела.

 

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

отсюда все эти постоянно-переменные составляющие зарплаты, системы оценок и т.д. Капитализм, одним словом.

Дык вот! Нам, строителям коммунизма, с ними не по пути! :))

Я отталкиваюсь от того, что человек изначально работать хочет, надо просто (хотя это конечно и не просто :)) создать ему условия и замотивировать

Нормальная, здоровая организация это коллектив единомышленников, которые делают одно общее дело ради одной общей цели

Это идеал к которому надо стремиться.

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

 

Учёт важен. Необходим. Но не надо делать культа из этого.

[Прохожий]

 

Учёт важен. Необходим. Но не надо делать культа из этого.

Это точно!

 

Только вот беда, идеал недостижим :( Приходится работать с тем, что есть. Особенно, если число участников процесса исчисляется десятками.