Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Леонид

Страницы: « 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 32 33 34 »
166
Можно я задам встречный вопрос? Мотивация аналитиков чем-то принципиально отличается от мотивации сотрудников других ролей в ИТ?

Встречный по отношению к чему?
Если подходить принципиально - нет, не отличается. Поскольку все люди из примерно одной культурной среды. Вот при работе с иностранцами, может, и есть различия, не проверял.

В нюансах может отличаться (догадка). Есть более творческие направления (аналитика, например), есть менее (тестирование).

Можно, как это часто бывает, придумать пустые KPI, на основе которых будут раздаваться "слоны". Но мне кажется, что эффективнее толковых непосредственных руководителей, которые проводят персональные беседы с подчинёнными и которые при этом заинтересованы в их развитии, пока что ничего не придумали.

Не надо придумывать КПИ. Кроме вреда - никакой пользы. Ан масс.
Рулит грамотный наблюдательный начальник, не зацикленный на карьеризме или иной форме личной выгоды.

167
Такая схема не премирует какого-либо одного участника проекта, а поощряет всех. От РП до тестировщика и тех.писателя, спеца по обучению.
Мне кажется это справедливым

А вот и посмотрим.

Был проект, с бюджетом на премирование, который распределялся на всех участников проекта пропорцианально кол-ву потраченных часов

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

ЗП участника

Иными словами, человек мог впахивать как негр (гораздо сильнее белого господина за соседним столом), но из-за того, что ставка у него меньше - получил все равно меньше?

и так скажем его вкладом в проект (определяется РП в размере от 0-1, т.е можно ничего не получить (премии) или получить всю рассчитанную премию).

А это мой любимый момент во всех таких схемах. Если есть "определяет РП", то все остальное нужно лишь для придания иллюзии "прозрачности" схеме. На деле всё будет определяться начальником. В рамках, определенных ему начальником сверху.

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

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

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

* * *

Могут спросить, что же я имею предложить в таком случае, если вообще. Да! Я имею сказать, что такие вот "схемы" в качестве мотивационных - они от лукавого. Дурить институток годны, но вряд ли годны для большего, но при этом имеют вышеописанный отрицательный эффект.

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

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

168
Ну если у вас принимают документацию, то действительно будет полегче мотивировать аналитиков.

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

На тему мотивации творческого люда видел интересную рисованную видюшку (требуется минимальное знание английского): http://www.youtube.com/watch?v=HC5o6TOf0IE

Есть не самая плохая книга некоего Пинка Д. "Драйв. Что на самом деле нас мотивирует".

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

169
Наше руководство  - аналитиков никак не мотивируют.

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

Считается, что от аналитиков нет выхода, делают всё  программисты.

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

170
Мотивацию аналитика нельзя создать, но можно сохранить. Поэтому "простимулировать" слово ошибочное.

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

Хех... Слово "простимулировать" у меня давно вызывает исключительно негативное восприятие. Опыт подсказывает, что применяется оно тогда, когда из тебя собираются выжать еще что-то сверх.

171
расскажите как у Вас построена система мотивации сотрудников работающих аналитиками?

Хреново построена. Я пока не видел ни одной корпоративной "системы мотивации", которая возбуждала бы на свершения. В редком лучшем случае, они не мешали. Чаще являлись системами демотивации.

Как еще кроме как например какой то % от прибыли по проекту можно простимулировать аналитика?

Это, кстати, пример демотивации. Почему? Потому, что прибыль у проектов разная. У какого-то побольше, у какого-то отрицательная. И если подходить в лоб, то один аналитик будет завидовать другому, сидящему за соседним столом на более рентабельном проекте. В пределе разовьется система кумовства и взяток, посредством кторых тебя будут сажать на жирный проект. Ну, примерно как в системе дружбы таксистов с диспетчерами.

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

172
Нужно проанализировать степень разработанности вопроса в современной научной литературе,


Какого вопроса?

и проанализировать динамику ВВП с учетом инфляции за последние 20 лет, тоесть с 1996-2015г.
Поможет кто, или хотя бы направить в верное русло.


За этим на официальный сайт Росстата, там есть.

173
Нет, не так. Если Брать пост SALar

Не тот пост берете. См. №16.

Как все плохо то.... Ни спрогнозировать, ни факт посчитать.

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

Правильно ли я понимаю, что единственно возможным вариантом является ввод коммунизма - программистам и аналитикам платить по потребностям, а сроки устанавливать полагаясь на их сознательность  ;D

Хех... Наилучший результат, который я видел в разработке больших и отвественных систем, был именно у такой команды. Сидели они в своей конторе, прорабатывали себе нормативку, математику, сами писали по ним софт. Более 20 лет так работали. Ни тебе энсотмиллионных контрактов, ни корпоративов в куршавелях. Только зарплата инженеров с соразмерными премиями. Периодически отмечали юбилеи друг дружки тортиками под чай. Кому 60, кому 70.

А система их, что характерно, работала. Пока "молодые и амбициозные" (каждый год новые) приходили их автоматизировать.

Но будем считать, что это случайное совпадение. Безусловно, молодой и амбициозной команде, имеющей на оснащении 10 программных систем энтерпрайз-уровня и бегло изъясняющейся на 10 нотациях, любая задача по плечу. Особенно если энсот лямов ее хозяевам отсыпать. :)

Тем не менее такие возможности есть.

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

Насколько все удобно надо пробовать - я ж сразу обозначил, что делаю эту задачку в контексте изучения возможностей EA.

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

Проще думать над моделями (пусть даже неточными и грубыми) - мне по крайней мере. Рисовать модели более менее все равно в чем. Оценка трудоемкости, выпускаемая по кнопочке - бонус

Вот это и смущает. Вы стремитесь думать своими категориями над тем, для чего давно придуманы другие (и придуманы не просто так).

Да не обращайте внимания, в конце концов. Оно ж меня смущает, а не Вас. :)

174
По первому пункту: Придется мониторить весь документ при изменении, а не один раздел.

Это гораздо легче, чем заставить программистов искать "свои" поля в какой-то общей свалке. Особенно когда их много.

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

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

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

P.S. Кстати, про валидацию вообще и "условную" в частности. В отечественной практике эта активность издавна носила куда более осмысленное и говорящее само за себя название "форматно-логический контроль" (он же ФЛК). Ух, сколько аналитиков и проектов набили шишки из-за банального незнания этого названия... :)

175
Вопрос не в самой оценке, а в том, что варианты использования вполне могут стать сквозной аналитикой, метрикой проекта.

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

Да. Это то, о чем писали я и SALar чуть выше. Оценка по аккуратно заполняемым таймшитам - оценка пост-фактум. Точная, как у патологоанатома. Вот так действительно можно посчитать затраты проекта.
Ну, это если предположить, что в шытах шыта не будет. Чего я за свой некоторый опыт еще не видел: как только людей заставляют писать, чем они занимались (и не дай Бог, еще и решения какие-то принимают на основе ими написанного), практически на всех разом нисходит вдохновение и "трудятся" они на бумаге по 9 часов из 8. Причем над самыми животрепещущими задачами.

Понятно, что планирование в EA не будет таким удобным, как в проджекте, а трекинг не таким удобным как в джире, но зато в EA можно держать ВСЕ виды моделей, в нем можно настраивать документирование, кодогенерацию и держать в самом проекте "вручную" написанные исходные коды (опять же не пробовал, но такие возможности есть)

Не слышал о применении ЕА в качестве репозитория кода. От слова "совсем". На Вас за такие инициативы программисты могут... обидеться. Примерно как ПМы за затаскивание их в EA вместо родного проджекта. :)

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

Тут как с грибами: есть можно все, но не все стоит.

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

Я боюсь, что именно так оно и есть (про фантазии).
И нихрена себе у Вас представление про "облегчить"...

176
Ну да. А текущая себестоимость проекта и ожидаемая стоимость совершенно неинтересные показатели...

Вы правда собираетесь выводить их из оценки стоимости кучки вариантов использования?

Как раз и хочется воспользоваться EA не в качестве UML рисовалки, а в качестве полноценного средства управления разработкой. В том числе и ее бюджетом. Потому как без такой автоматизации на подобные расчеты много времени уходит.

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

177
Никакого очковтирательства нет, нормальный заказчик прекрасно понимает суть данного ценообразования. И то что результат такой прикидки довольно приблизительный прекрасно понимает.

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

Наверное, есть исключения, когда этим занимаются из спортивного интереса. Или возлагают по наивности некоторые надежды. Только не дороговато ли получится? Ведение таких моделей требует кропотливой работы и постоянного внимания. Не лучше ли пустить их на создание результата?


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

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

Соответственно всегда можно проводить анализ, что в бюджете, а что нет.

Скорее, успокаивать себя мыслью о том, что "у нас все схвачено".

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

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

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

В таком качестве - да, запросто. Будет выглядеть солиднее, чем вспышки на Солнце или Луна в созвездии Козерога.

Суть использования UC не в точности прогнозирования стоимости, а в задании структуры стоимости, которой впоследствии можно управлять

Хреновая структура стоимости получится. И управляться будет хреново (вернее, структура управляться будет хорошо, хреново будет с "управлением" стоимостью).

178
Берем произвольную стоимость, манипулируя параметрами подгоняем под результат и потом выдаем это за обоснование. И втюхиваем доверчивому заказчику.

Тссс! Не пали основной метод ценообразования.

179
Если взять три примерно одинаковых команды (A, B, C) и два примерно одинаковых проекта (K, L) и каждую команду попросить сделать каждый проект, то вполне может получиться такой разброс в трудоемкости:

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

180
А вот как проверять на адекватность, пока что идей нет.

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

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

Страницы: « 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 32 33 34 »