Pull to refresh

Comments 320

А можно опрос добавить опрос? Было интересно посмотреть статистику.

Спасибо за полезное предложение, добавил

Опрос не правильный. Нужно четыре варианта:

Надо ли премировать вторую команду?
* Да
* Да, но не дам.
* Нет
* Нет, но дам.

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

Считайте что такое право у вас есть.

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

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

При этом никто здесь еще не задался вопросом(по кр.мере в комментариях ниже не прозвучало): превысила ли эта самая рекордная прибыль, превышенный в разы бюджет? Вполне возможно, что расходы превысили эту самую «рекордную прибыль с проекта», и премию естественно давать не за что.

Вот вам самый простой пример:
«Дайте мне несколько миллиардов долларов, я куплю вам FaceBook/Google/Apple, и принесу вам рекордную прибыль (которую вы еще никогда не получали = рекорд) !»
При этом никто здесь еще не задался вопросом

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

Пункты 1 и 2 друг другу противоречат, судя по всему компания уделяет большое внимание соблюдению сроков и бюджетов проектов, а не мотивации

Пункты 1 и 2 друг другу противоречат

Менеджмент компании не разделял с вами эту точку зрения.

Это история про MS Word, довольно известная

Нет, но полагаю, что под рамки задачи подходит много реальных историй

А можно ссылочку на историю

Подскажите пожалуйста, что за история

Умаслите нас, pls, историей. На просторах не находится…
Присоединяюсь. Расскажите, плиз, историю.
Ну офигеть просто :) 4 человека попросило.

Искал в Инете долго, но в success stories Microsoft, а надо было в другом месте. Помню же, что не из пальца высосал :)

Вчера всплыло в голове, откуда взял — слышал это на одном из семинаров Московского отделения PMBoK. Сразу же и нашел источник см. страницу 8.

Причем, по поиску в инете же на эту тему — не совсем так, эта story совсем не success, а всего лишь более-менее приемлемый happy end, с раздолбайством менеджмента данного проекта в процессе.

Приношу извинения спрашивавшим за задержку с ответом.
скопирую сюда, чтобы всем не лазить в источник
Факты:
• Разработка продукта длилась 5 лет вместо одного года;
• Бюджет проекта был превышен более, чем в 5 раз;
• Это - провал?
// Нет - это был MS Word
Да стоит, они вполне её заслужили.
То что бюджет выше и сроки провалены, так это недоработка менеджера проекта, вот его премию можно им и отдать :)

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

Депремировать тех, кто ввёл эту систему.

Это понятно, а с командой как поступите?

Я всё же не управленец, да и прочих деталей ситуации в фирме не знаю.
Навскидку мысль: если нельзя премировать — надо искать другие пути поощрения. Зарплату повысить, например :-).

UFO just landed and posted this here

А с командой что делать?

UFO just landed and posted this here

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

Безусловно премировать. В данном случае люди, стараясь сделать проект, рассматривали его как некий стартап, или голова в кустах или грудь в крестах. Если их за успех не премировать — это будет им и всем другим напоминанием о том, что руководству плевать на успехи команды, и следующий подобный проект будет реализовываться командой так чтобы а) уложиться в сроки и бюджет, и б) свалить вину за его кривизну и провал на кого то другого. Как вы понимаете, подобный вариант легко может похоронить как команду (ибо не все люди готовы работать по крысиным принципам), так и организацию в целом (ибо убытки могут быть так умно скрыты, что узнать о них будет затруднительно).
Выдать надо. Но четко определить что эта перемия не связанна с премией за сдачу проекта в срок.
Вот кстати да, согласен с вами. Если вторую команду не поощрить, мотивация упадет очень сильно. Можно управлять размером премии, способом выплат и т.п., но премия нужна.
Между 1-м и 2-м пунктами, а также между 6-м и 7-м очень слабая связь. Мотивация сотрудников и сроки проекта друг с другом не особо пересекаются. Также просрочка нового проекта могла привести к уменьшению прибыли, хоть она всё равно и осталась рекордной. Собственно высокий результат вторая команда не показала, поэтому и премии ей давать не следует.

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

Для ответа на этот вопрос недостаточно входных данных. Зависит от анализа ретроспективы. Может, были спущены сверху нереальные сроки, или задача такая, что вообще неизвестно было, можно ли ее решить в принципе. А может, прополимерили все полимеры. :-) Хотя с формулировкой про энтузиазм вряд ли прополимерили — тогда, конечно, вознаграждение нужно, но не в виде той самой премии из п.2, а что-то еще. А потом поменять эти дурные правила.

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

Тут дело-то не в том, как оценивать команду, а в том, что изначальные правила были неверны. Поэтому нужно сначала поменять правила, а потом, на основании этих правил и решать как премировать команду.
В рамках текущих правил премию-бонус не давать (и не надо путать с депремированием, свой фикс команда же получила?).
Если «сверх прибыль» получилась в связи с тем что результат был действительно лучше планируемого и/или в следствии того что в процессе создания была создана технология/методика которые не входили в первоначальный план — тогда выдать «бонус» за данный героизм, но в сумме меньший чем за исполнение в срок.
Т.е по другому — команда выполняла свою работу, получала ЗП, финансовые риски не несла, условия сдачи не выполнила => нет бонуса.
UFO just landed and posted this here
Премировать нельзя. Если в компании не предусмотрены премии за «выстрелившие» проекты (по результатам прибыли / etc.), то и не за что премировать.
Выдавая премию вы поощряете команды нарушать сроки / бюджет, а так же демотивируете первую команду. Один раз вам повезло и проект выстрелил, но нет никаких гарантий что такое повторится.
(Говорим про программистов) Премия и мотивация сегодня слабо связаны. Цель премии — удержание хороших сотрудников в основном. Если у компании в целом хорошая прибыль, то надо премировать хороших программистов или тех, кого собираешься удерживать.

Если у вас действительно есть такие программисты или менеджеры от действий, которых сильно зависит и напрямую (!) зависит прибыль компании, то это часто уже даже не премия называется, а % от сделок, продаж, опцион и т.п.
UFO just landed and posted this here
Любой менеджер знает, что рядовые сотрудники после получения премии начинают работать только хуже, а вот менеджеры — лучше.
Главное — убедить в этом этих самых рядовых сотрудников.
Команда, так удачно выстрелившая рискованный стартап — это далеко не «рядовые сотрудники». Команде — дать бонус, перекрывающий депремирование за нарушение сроков и бюджета (как я правильно понял из статьи/условия задачи, прибыль — с лихвой окупила все понесённые риски. если нет — тогда бонус сделать меньше депремирования).
То, что проект выстрелил — это не «повезло», это итог сознательного решения — делать хороший продукт, а не соблюдать сроки и бюджет.

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

Есть лишь вероятность, что команда, создавшая один отличный продукт, сможет создать другой продукт не сильно хуже первого. Просто потому, что у неё уже есть know-how, как делаются хорошие продукты.

Собственно делать хорошо, но не выдерживать сроки — это менеджерское решение команды. Да, пошли наперекор решению вышестоящих менеджеров. Но выиграли. За это и премия.
То, что проект выстрелил — это не «повезло», это итог сознательного решения — делать хороший продукт, а не соблюдать сроки и бюджет.

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

Я исхожу из простого факта — такого рода задача с подвохом вообще не имеет верного решения. Раз предлагается её решить — значит подвоха нет, а все пропущенные данные — несущественны для решения задачи.

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

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

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

Согласен. Вероятно, энтузиазм помог. Но с другой стороны, это также даёт основания полагать, что сначала они сдали проект, с серьезным превышением сроков и бюджетов, а уже потом, через какое-то достаточно продолжительное время, оказалось, что проект «выстрелил». Это тоже самый распространённый вариант развития событий.
Мы не знаем почему выстрелил. Из условия задачи я не увидел прямой связи «работали с энтузиазмом и из за этого выстрелил». Из практики — сложно предсказать что выстрелит а что нет. Энтузиазм тут играет далеко не первую роль (а очень часто и наоборот).
Да и дело даже не в этом. Если вы говорите А, а делаете Б — вы теряете доверие. Сказали «премия за сроки», «нет премий за результат» — значит придерживайтесь его. Со стороны других команд тот факт что вы выдали премию говорит о следующем: «вы можете срывать сроки, всё равно получите премию». В долгосрочной перспективе вы проиграете. Можно ещё раз пересмотреть стратегию, и если рисковать и срывать сроки и бюджет окажется лучшим решением — откажитесь от премий за сроки и введите премии за результат. Но в текущих условия, ИМХО, премировать — плохое решение.
Да, именно так. Вы можете соблюдать сроки и бюджет — и получите премию независимо от результата работы. А можете рискнуть и сорвать сроки — скорее всего вы на этом проиграете, но есть шанс и выиграть, если в итоге ваше поведение окажется выгодным для фирмы.

Любое поведение, приведшее к выгоде дял фирмы, должно быть вознаграждено. Логично? А если выгода крупная — значит полезно дать часть этой выгоды работнику в виде премии.

Тут интересней другой вопрос — надо премировать за соблюдение сроков и бюджета, если это привело к ущербу для фирмы. Например, к репутационному. То есть сделали, не «как надо», а как влезло в бюджет. И с хреновым качеством. Надо ли такое премировать? По букве правил — надо. А по существу?
Любое поведение, приведшее к выгоде дял фирмы, должно быть вознаграждено. Логично?

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

По букве правил — надо. А по существу?

И по существу надо, если не было каких-то других условий. Например, соблюдения стандарта качества. Если руководитель назначил премию за скорость/бюджет, и при этом не разработал стандарты качества или критерии приемки работы, то это уже его проблема, а работники свою премию заслужили.
«Соблюдение правил игры» в ущерб интересах фирмы приводит к демотивации. И у тех, кто получил премию, и у тех, кто не получил, появляется стимул не болеть за общее дело, но соблюдать правила игры.

Ошибка менеджмента в том, что правила назначения премии были назначены «вбок» к интересам фирмы (прибыли). И надо эту ошибку признавать и исправлять.

В задаче все не настолько радикально
Есть правило "премировать за соблюдение сроков и бюджета"
Нет правила "ни в коем случае не премировать за что-то еще"

«Соблюдение правил игры» в ущерб интересах фирмы приводит к демотивации

Что такое «интересы фирмы»? Я так понимаю, в общем случае всё сводится к одному интересу — заработать больше денег своим бенефициарам. А всякие там захваты рынков, мотивации персонала и т.д., всё это способы достижения главной цели.
И в общем случае отсутствие четких правил внутри компании влияет негативно на её прибыльность. Исключения/контрпримеры бывают, но они картину в целом не меняют.
Вот, например, эти парни нарушили правила, превысили всё и вся, и победили. Здорово, хорошо. Надо ли такое поощрять, чтобы и другие думали, а не копать ли стахановскими темпами вот то новое интересное направление, про которое нифига сейчас не понятно? Я не уверен. На одну такую победу может быть десять поражений. Когда запоротый бюджет и сроки оседают большим минусом в финрезультате компании.
Надо ли остальным давать понять, что если они не будут стараться соблюдать сроки/бюджет, но в итоге останутся в прибыли, то им тоже что-то перепадет? Я тоже не уверен.
В предельном случае работа по-правилам называется обструкцией (она же итальянская забастовка). В не предельном — работа по правилам просто менее эффективна, чем работа на результат.

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

Главное, что надо понимать работнику — это мы работаем ради кратковременной прибыли, или на долгосрочную перспективу. А правила — это всего лишь костыли для типовых случаев. Если случай не типовой — эффективней решать по уму, а не по правилам. Об этом много писал Milfgard.

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

На одну такую победу может быть десять поражений.

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

Знаете, в чем главное отличие? Я считаю, что мои коллеги и подчиненные — крутые и умные. А вы считаете их глупыми неучами. Гм, ну кто кого себе набрал…
В не предельном — работа по правилам просто менее эффективна, чем работа на результат.

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

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

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

Знаете, в чем главное отличие? Я считаю, что мои коллеги и подчиненные — крутые и умные. А вы считаете их глупыми неучами. Гм, ну кто кого себе набрал…

Не угадали. Я не смотрю на своих сотрудников через призмы, фильтры и розовые очки. Я стараюсь воспринимать их такими, какие они есть. Ни вы, ни я, ни ваши коллеги не являются ни крутыми, ни умными, ни неучами. У нас у всех есть сильные и слабые стороны. Мы все делаем и умные поступки, и ошибки. Можем обидеться из-за какой-то фигни или поступить некрасиво. У всех есть какие-то индивидуальные психологические нюансы.
А корпоративные правила, кстати, в таком случае нередко помогают избежать «острых углов» в отношениях команд. Они появились не потому, что узурпаторы-капиталисты решили подавить индивидуальность работников, а как результат опыта в решении проблем управления. Когда вас пятеро, вы сами между собой прекрасно договоритесь (в большинстве случаев, да :-). Но если вас уже хотя бы пятьдесят, в такой команде будут появляться и обиды, и несправедливость, и тому подобные гадости. Если не регламентировать основные точки конфликтов, например, субординацию и мотивацию. И соблюдать этот регламент.
. Я говорю о том, что надо соблюдать имеющиеся правила.

Как уже заметили правила не давать премию, если сроки не соблюдены — нету.
Наверное, в таком случае лучше не играть в «поймай единорога», а инвестировать в проекты с более «ровными» перспективами?

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

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

Ни вы, ни я, ни ваши коллеги не являются ни крутыми, ни умными, ни неучами.

Почти все мои коллеги — круты безумно. Один в одиночку написал софт для гаишного фотопадара, другая — технический писатель по ГОСТ. Это фантастически редкое умение — писать по ГОСТ понятно. А чтобы ещё именно эта работа нравилась… Третий ушел с должности ИТ-директора в юниоры. Просто потому, что как ИТ-директор сети магазинов он достиг потолка. Могу и про остальных рассказать… Про то, как гендиректор в 6 утра едет домой поспать, а в 10 утра — опять на работе.
Когда вас пятеро, вы сами между собой прекрасно договоритесь (в большинстве случаев, да :-)

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

Субординацию, говорите? Программист — все-таки творец. Если не путаю, то Достоевский постоянно срывал сроки. Помните его издателей? Не? А кого вы помните из тех, кто писал в срок? Донцову?

Это работа менеджмента — помножить согласованные с программистами сроки то ли на пи, то ли на е (то ли и на пи и на е). А работа программистов — творить.
Как уже заметили правила не давать премию, если сроки не соблюдены — нету.

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

Как я уже говорил, в тот момент, когда разработчики вытирают пот со лба и говорят, вот, готово, получайте вашу программу, у них ещё нет никакой прибыли и успеха. У них есть только сорванные сроки и проваленный бюджет. Успех к ним может прийти только потом, в перспективе. И в результате слаженной работы программистов, маркетологов, продажников. И это уже совсем другая история.
Про то, как гендиректор в 6 утра едет домой поспать, а в 10 утра — опять на работе.

У нас с вами разные понятия крутизны. Я не считаю, что у человека, который всю жизнь отдаёт работе, эта самая жизнь полноценная. Равно как и не считаю крутым в каком-то зрелом возрасте бросать свою карьеру и начинать всё сначала, но в другом направлении. Это всего лишь признак того, что ты потратил зря большой кусок своей предыдущей жизни.
А работа программистов — творить.

Работа программистов — это работа инженеров. Один инженер творит дизайн нового спорткара, а в это же время тысяча других инженеров чертят стопятисотые водопроводные трубы, градирни, кабель-каналы, просчитывают нагрузку на полы и освещение в офисах. Поэтому не надо слишком возвышать эту работу. Программистов — миллионы, а интересных романтических стартапов сотни. Их на всех не хватит. Кому-то приходится интернет-магазины верстать, кому-то проводки в 1С наворачивать.
По-моему, правило «премия положена в том случае, если соблюдены такие-то условия» не имеет каких-то разночтений и лазеек.

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

По-моему, правило «премия положена в том случае, если соблюдены такие-то условия» не имеет каких-то разночтений и лазеек.

Это правило не отрицает назначения других премий, например за качество продукта. Более того, можно дать и премию за срыв сроков — например в виде килограмма тухлых помидоров. :-) Вы там видимо прочли «только в том случае», а слова «только» там нет.
Успех к ним может прийти только потом, в перспективе. И в результате слаженной работы программистов, маркетологов, продажников. И это уже совсем другая история

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

Собственно по количеству предзаказов и первым дням продаж и определяется успех.

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

Это заблуждение. Человек, умеющий выкладываться в одной деятельности — как правила достигает успеха и в другой. А человек, работающий от сих до сих — так же вяло занимается и хобби. Так что мы радуемся, когда наш гендиректор ездит на выходные в Италию — посоревноваться в очередной регате. Или поболеть за сына (он член молодежной сборной РФ и тоже работает у нас)

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

Мне кажется наоборот, остаться после института в профессии, по которой работал с 13 лет — это значит учиться зря. Все-таки диплом не должен быть просто бумажкой. А в профессии начальника ИТ-отдела он достиг потолка задолго до окончания института.

Опыт показывает, что успешный человек может сменить профессию и в 70 лет. Причем сменить кардинально — с разработчика АСУТП на администратора дома культуры. Основные условия — самообучаемость и умение выкладываться на работе.

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

Опять 19 век. С конца 20ого это все делает САПР. В середине и начале 20ого — для этого были чертежники.
просчитывают нагрузку на полы и освещение в офисах

Мамочки! что у вас за нищебродство? Полно программ, которые это делают. Вы бы ещё смету руками почитали.

Кому-то приходится интернет-магазины верстать, кому-то проводки в 1С наворачивать.

Ну так не путайте программистов с верстальщиками. Это разные профессии. И в 1С — полно творческой работы (техническую она как раз делает сама). Вы хоть раз искали, почему у вас шахматка не сходится? Поищите, квест ещё тот. :-))
Программистов — миллионы, а интересных романтических стартапов сотни. Их на всех не хватит.

На тех, кто хочет интересную работу — её хватает. Беда в другом — многие хотят работать только от сих до сих. А интересная работа занимает всю жизнь.

У меня стаж больше 30 лет. И ни одной неинтересной работы. Впрочем, может быть это мое отношение к работе такое.
Это какой-то позапрошлый век. Маркетологи главное должны были сделать до начала разработки — определить, какие параметры продукта будут успешными на рынке.

Я вас огорчу. Если вы создаете новый продукт, то и в позапрошлом, и в прошлом, и в этом веке, и в следующем, пока вы его не сделаете, вам никакой маркетолог не рассчитает достоверно реакцию рынка. Даже такие монстры как Майкрософт или Гугл, с огромными бюджетами, не в состоянии достоверно оценить востребованность своих новых продуктов, и выпускают их «на авось», экспериментируя и ошибаясь.
Продажники — должны были заключить первые сотни и тысячи договоров и получить предзаказы (в идеале с предоплатой)

Угу. Тысячи договоров на неизвестно какой, но несуществующий продукт. И много ли таких случаев в природе, если не считать краудфандинг, где деньги платят не покупатели, а рискующие инвесторы?
Опять 19 век. С конца 20ого это все делает САПР

Сама делает? Вот так приходит к ней заказчик, и говорит: «САПР, рассчитай мне вон по этому проекту освещение и водопроводные трубы». А та пожжужала, и сразу проект выдала? ;)
Я вас огорчу. САПР — это всего лишь инструмент. Который сам ничего не умеет делать и рассчитывать. Всё это делает, как ни странно, всё тот же инженер. Который по-прежнему не только данные в калькулятор вбивает, но ещё и понимает, как САПР работает.
Мамочки! что у вас за нищебродство?

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

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

Зависит от степени достоверности и от иновационности. Если вы собираетесь сделать то, что уже есть на рынке, с блэкджеком и шлюхами с куртизанками и луна-парком и по цене в 2 раза дешевле — сбыт у вас будет.
Тысячи договоров на неизвестно какой, но несуществующий продукт. И много ли таких случаев в природе

Много. Даже госконтракты такие бывают — контракт на разработку со сроком месяц (а само решение делать год). То есть работа начинается задолго до объявления конкурса.
Это всё редкость на потребительском рынке. А в B2B — обычное дело.

Через какое время после объявления нового айфона он попадает на прилавок? Так что контракты там подписаны и авансы задолго до официального выхода продукта. Аналогично — новые процессоры и много-много что…

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

Вот так приходит к ней заказчик, и говорит: «САПР, рассчитай мне вон по этому проекту освещение и водопроводные трубы». А та пожжужала, и сразу проект выдала? ;)

Примерно так, если проект уже в САПР. Подробности были в блоге КРОК. Более того, я вас удивлю, но даже платы программы разводят. И даже бесплатные онлайн-варианты есть. А разводка электрики и сантехники — проще разводки плат.
Судя по вашему окружению, просто у вас жизненный фокус сильно смещен в сторону работы

А что ещё в жизни делать? Водку пьянствовать и безобразия нарушать? Любым хобби тоже надо заниматься на профессиональном уровне. Так что хобби — это просто бесплатная работа по второй профессии.

А вообще, если десятка профессий в руках нету — ну как бы не мужик это.
Зависит от степени достоверности и от иновационности.

Ну да. Но мы же как раз про нечто инновационное говорим. Тюнинг существующих продуктов, естественно, предсказуем. Но рынок обычно не взрывает и высоких прибылей не приносит.
Это всё редкость на потребительском рынке. А в B2B — обычное дело.

Это тоже зависит от инновационности. Предзаказы на седьмой айфон от тех, кто видел популярность шестого, пятого и т.д. будут сами сыпаться. А вот попробуйте своих партнеров убедить подписаться под покупку партии принципиально нового продукта. Пока они от вас не получат живой прототип, фигушки.
Примерно так, если проект уже в САПР.

Не, ну понятное дело, если в САПР ввести данные, она вам посчитает.
Более того, я вас удивлю, но даже платы программы разводят.

Да, а я вам по этому поводу могу рассказать, что сначала вы её настраиваете. Вам нужно ввести типы шин, параметры разводки для каждой — здесь под питание поширше, здесь дифференциальная пара и т.д. Подобрать библиотечки компонент, т.к. в стандарной поставке есть далеко не всё. Потом нарисовать схему вашего девайса. Altium Designer ведь за вас её не придумает. Потом расставить элементы по плате. Определиться, где контакные площадки, где межслойные переходы. Потом вы можете запустить трассировщик, САПР вам оттрассирует плату. А напоследок вы будете исправлять его косяки. А ещё на живом прототипе вы увидите просадки, из-за которых надо будет или перетрассировывать, чтобы укоротить проводники, или конденсаторами допитывать.
Вы думаете, я с вами спорю, потому что не видел эти страшные программулины, а не наоборот, потому что я с ними работаю и знаю, сколько работы по-прежнему делает человек? ;)
Говорить, что расчеты делает САПР, а не инженер — это все равно, что говорить, что уколы в попу делает шприц, а не медсестра.
А что ещё в жизни делать?

Риторический вопрос. Я в свободное от работы время научился кататься на сноуборде, защитил кандидатскую, съездил на Большой Адронный Коллайдер, читал лекции студентам, женился и родил (вру, не я родил) дочку, строю дом и т.д. В общем, ИМХО, есть чем заняться в свободное время кроме работы.
Но мы же как раз про нечто инновационное говорим.

Ну как по мне — первый полупрофессиональный GNSS-приемник с GALILEO — это прорыв. Есть дорогие (от полумиллиона) профессиональные приемники. Есть дешевые, но они или без фазы или без GALILEO. А это прорыв — цена 2 труб + GALILEO.

Чуть про конкурента
Ну Да, есть UBlox, вот только в data sheet читаем: The NEO/LEA-M8T modules provide raw measurement data for civil L1 band GPS, GLONASS and BeiDou signals including pseudo-range and carrier phase, Doppler and message payloads. То есть никакой фазы на GALILEO у него нет.

Да, а я вам по этому поводу могу рассказать, что сначала вы её настраиваете

Я в курсе. Но нормальное проектирование идет в САПР. Если рисовать схемы от руки, а потом — в altium designer — будет плохо. А если сразу начать с альтиума — не так все страшно./
потому что я с ними работаю и знаю, сколько работы по-прежнему делает человек? ;)

я в курсе, что всем хочется ещё больше автоматизации. :-) Но и та, что есть — неплоха.
Я в свободное от работы время научился кататься на сноуборде, защитил кандидатскую, съездил на Большой Адронный Коллайдер, читал лекции студентам, женился и родил (вру, не я родил) дочку, строю дом и т.д.

Остапа понесло? Чтение лекция это что, развлечение или работа? Кандидатская, это какой род деятельности, развлечение или работа? Бесплатная работа — не перестает быть работой.

Наука вообще — удовлетворение собственного любопытства за чужой счет. Но при этом странно относить науку к развлечениям.

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

Ну в общем давайте не будем спорить о терминах. А то мой коллега считает отдыхом разводку плат в альтиуме. :-) Ну да, по сравнению с отладкой кода — вроде как и отдых. :-)
Чтение лекция это что, развлечение или работа? Кандидатская, это какой род деятельности, развлечение или работа?

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

Интересно, для вас кандидатская — это спорт, самообразование, общественная деятельность, хобби или работа? :-)
Профессиональный спорт — это вполне работа.

Под «заниматься в спортзале» я имел в виду не профессиональный спорт, и вы это прекрасно поняли. Но прямой ответ, он же неудобный, да? ;)
для вас кандидатская

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

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

Мой сборник песен Юрия Визбора — для меня тоже работа. Не, я был удивлен когда мне об этом сказали профессиональные составители сборников. А ещё больше — когда увидел упоминание о нем в журнале «Советская библиография».

Педагогика — тоже работа. Просто потому, что или воспитываешь профессионально — или лучше не воспитывать. Тем, кого я вытащил из беспризорников — уже 26-28.

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

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

Самообразование… самообразование у меня идет на основной работе. Ну вот интересно мне изучать программирование. Вот и изучаю уже 35 лет.

Но ещё раз — не вижу смысла о терминах спорить. У вас одна квалификация, у меня — другая. Смысл от этого не меняется.

Как бы вы не называли свою кандидатскую — но вы можете в науке зарабатывать. Как бы вы не называли свое хождение в спортзал — но ходите вы туда для удовольствия и никто вам за это хождение не заплатит.

То есть по смыслу — расхождений нет. Они лишь в терминах. А слова… это всего лишь асимметричный дуализм языкового знака.
UFO just landed and posted this here
Деньги — действительно не главное. Если есть ответственность за результат — это работа (пусть бесплатная — но работа). Если нет — это отдых.

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

Ещё раз повторю — это спор о терминах. У меня одна терминология, у вас другая. Не вижу смысла об этом спорить.

P.S. Ноев ковчег строили любители, профессионалы строили титаник.
UFO just landed and posted this here
А поделитесь опытом по части бумажной волокиты? А то меня из аспирантуры, походу, скоро выпрут из-за некоторых формальностей

Меня бы тоже выперли из-за некоторых формальностей. Я просто подошел к ученому секретарю и спросил, нет ли у них аспиранта или лаборанта, который хочет подзаработать, взяв на себя мою бюрократию. Таковых оказалось немало.
UFO just landed and posted this here
Это в какие категории записывается?

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

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

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

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

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

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

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

Так что мы имеем лишь обещание работодателя «за это -заплачу. Оно никак не запрещает платить за что-то иное.

Правильная аналогия такая. Вы заказываете на сайте гаджет, то есть обещаете его оплатить. Разве это запрещает вам купить ботинки? Деньги ваши, как хотите — так и тратите.
Все дело в том, что премии не являются наказаниями.
В данном случае премия и наказание — это просто числа, и по своим свойствам они абсолютно эквивалентны. Не верите? Делаем премию нормой, но регулируем ее размер. Даем всем стандартную премию в 50%, работягам — в 100%, бездельникам — в 5%. И внезапно бонус в 5% для сотрудника одновременно является и премией, и наказанием. Как же так?

Пример с УК состоит в том, что трактовка правил таким образом, что они допускают лазейки — это плохо. Люди этого не любят, их это демотивирует.

Если вы вводите правило «премии за сдачу в срок», а потом раздаете премии по своему усмотрению, то ваши подчиненные увидят, что грош цена вашим правилам и будут просто демотивированы. Ведь можно за сдачу в срок дать премию в 5%, а фаворитам, срывающим сроки — дать премию в 100%.

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

И в общем-то это правильно. Кто больше денег фирме принес — у того и премия больше.

Оффтопик про УК
Что касается УК — это очень особая область права, где не действуют аналогии. Тогда как во иных областях права работают и обычаи и аналогии. При этом у УК хватает неформализованных понятий, например порнография. Более того, смысл этих понятий меняется во времени, например изображение женщины в брюках лет 120 назад считалась порнографией.
Порнография вообще определяется экспертно, то есть обычный человек не может достоверно сказать, порно он распространяет или эротику. Вот такая от «определенность» в УК.

Это я вам говорю, как человек, модерировавший крупнейший в РФ видеочат.


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

А у работников есть выбор — сорвать сроки и с шансом 1% (или того меньше) получить большой приз. Или не срывать сроки — и иметь гарантированную премию. Это нормальный выбор везде, кроме школы. Привыкайте к особенностям взрослого мира. :-)
И в общем-то это правильно. Кто больше денег фирме принес — у того и премия больше.
А кто ответственен за подсчет того, кто больше денег принес? Может больше всего принес денег администратор, т.к. без него в критический момент все сервера бы легли и клиентов потеряли? Или больше денег принесла уборщица, т.к. без нее в офисе была бы грязь и люди бы болели/увольнялись? Или может больше всего денег принес CEO со своим видением продукта, а остальная команда — это просто бездумные рабы, которых легко заменить? Именно для того, чтоб уйти от человеческого фактора в этом вопросе и придумывают правила. Вы же предлагаете забить на правила и использовать человеческий фактор. Это глупо делать после того, как правила уже были публично объявлены, т.к. просто уничтожает доверие к вам.

Это нормальный выбор везде, кроме школы. Привыкайте к особенностям взрослого мира

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

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

Правильно ли отпустить на свободу убийцу, если его вина не доказана, но практически все абсолютно уверены, что он виновен? Представьте себе, правильно — отпустить. Т.к. непоколебимость правил гораздо ценнее, чем отсутствие убийцы на свободе.

Дайте угадаю: опыта лидерства у вас нет. Зато есть опыт наемного программиста, который позволяет вам очень легко ассоциировать себя со второй командой. Из чего и складывается ваша позиция.

Вы легко предлагаете поступиться собственной integrity в угоду одной команде. Т.е. показать всем остальным командам что ваши слова ничего не стоят, лишь бы не отвечать за собственные ошибки. По сути вы предлагаете жить «по понятиям», а не по законам, и при этом рассказываете про взрослый мир и делаете намеки на школу?

И это только то, что касается поиска лазеек в собственных правилах. Само по себе правило «премируем за коммерчески успешный проект» абсолютно несостоятельно без введения симметричного правила «штрафуем за коммерчески провальный проект». И эти правила давно реализованы в виде опционов, но это явно не случай описанный в топике, поэтому отношения к делу не имеет.
А кто ответственен за подсчет того, кто больше денег принес?

Владелец фирмы. Дальше он свою ответственность передает гендиректору, гендиректор — начальникам отделов…

Именно для того, чтоб уйти от человеческого фактора в этом вопросе и придумывают правила.

А зачем уходить от человеческого фактора? Тем более в распределении премий за творческую работу.

- Неважно, что твоя свадьба в 17 часов, по трудовому договору ты должен быть до 18 часов на работе.

Это вот предел — полное отсутствие человеческого фактора.

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

Не понимаю, откуда вы взяли обязанность объявлять все правила и отказываться от индивидуальных решений? ТК РФ накладывает такие обязанности лишь на особые виды поощрений вроде фотографии на доску почета (или бронзовый бюст на аллее).

Руководство объявило одно правило. И не более того. Оно не брало на себя иных обязательств.

Взрослый мир — это как раз принятие собственных ошибок и плата за них, а не поиск лазеек в собственных правилах.

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

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

Мда… тяжелое наследие времен СССР. Какой у вас цикл отладки получится? 2 года? Не, если правила ошибочны — лучше их отменить совсем. Вместо правила «премия за соблюдения сроков» вносить условия по конкретным проекта — вот за этот проект и этот этап будет премия, если сроки будут соблюдены.
Дайте угадаю: опыта лидерства у вас нет.

Всего лишь 40 лет занимаюсь педагогикой и всего лишь 20 лет тим-лид. У вас явно опыта в разы больше.

Зато ваш огромный опыт — относится к временам госплана и плановой экономики. И не применим в условиях гибкого производства.

Само по себе правило «премируем за коммерчески успешный проект» абсолютно несостоятельно без введения симметричного правила «штрафуем за коммерчески провальный проект»
.
Тезис очень спорный. Попробуйте его доказать. Или хотя бы доказать его законность с точки зрения ТК РФ.
А зачем уходить от человеческого фактора?
Затем, что иначе премии начинают получать те, кто улыбаются начальству, а не те, кто хорошо работает.

откуда вы взяли обязанность объявлять все правила и отказываться от индивидуальных решений? ТК РФ накладывает
Ваши команды вам перестают доверять, когда вы так себя ведете. Можете сколько угодно тыкать им в лицо ТК РФ, люди «творческих профессий» это лицемерие не потерпят.
Отказываться от индивидуальных решений не нужно, но нужно понимать, что решение идущее вразрез с установленными правилами уничтожает доверие и к правилам и тому кто их придумал. Последствия от этого могут быть гораздо хуже чем от невыплаченной кому-то премии, потому как затрагивают абсолютно всех, а не одну команду.

Мда… тяжелое наследие времен СССР
Не, если правила ошибочны — лучше их отменить совсем
Это у вас наследние СССР в виде жалкого идеализма. Понимаете, в поставленной задаче правила уже существуют. От них нельзя отказываться задним числом. Ну т.е. можно конечно, но это будет выглядит как обман для всех остальных: правила вроде есть, но в любой момент они задним числом могут переписаться. Кому-то пообещали премию за сроки, в за день до выдачи премий правила переписали и выдали ее тем, кто сроки сорвал. Прекрасный подход, ведь неопределенность и ложные обещания это именно то, что мотивирует людей.

Всего лишь 40 лет занимаюсь педагогикой и всего лишь 20 лет тим-лид.
Если это правда, могу лишь посочувствовать. За все это время вы так и не выработали в себе то, что называется integrity. Между «поступить как хочется» и «поступить как пообещал» вы с легкостью выбираете первое. Лидер из вас никудышный.

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

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

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

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

Что такое «компетентный» начальник? Напомню, по условиям задачи ваш «компетентный» начальник уже ввел эти правила. Он видимо и сам не знал, что он настолько компетентен, что эти правила были не нужны.

Т.е. он достаточно компетентен, чтобы не нуждаться в правилах, но недостаточно компетентен, чтобы их не вводить. Какой-то парадокс, вам не кажется?

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

Bonart,TimTowdy, Извините, что вмешиваюсь, но, по-моему, вы говорите об одном и том же, просто с разных сторон.
Всех людей можно разделить на две группы:
1. Те, кого больше демотивирует нарушение уже существующих неверных правил.
2. Те, кого больше демотивирует следование правилам в ущерб интересам фирмы.

Судя по всему, в коллективе Bonart людей второго типа больше, чем первого, поэтому верное решение (с точки зрения мотивации персонала) — премию дать. В то же время, судя по всему, в коллективеTimTowdy людей первого типа больше, чем второго, поэтому верное решение — премии не давать.

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

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

То, будет ли человек мотивирован или демотивирован, зависит не от того, что написано в правилах, а от того, как он их понял. Пример уважаемого TimTowdy убедительно показывает, что люди, которые понимают (по крайней мере без специальных разъяснений) это правило как эквивалентность, а не импликацию, существуют.
И на мой взгляд плясать надо именно от того, что за люди у вас в команде — как именно они поняли правила, что их в жизни мотивирует, и тд. И ответ на задачу от этого зависит.
В принципе верно, но разница в том, что сторонники премии второй команде практически полностью игнорируют вопрос демотивации всех остальных. Как будто его вообще не существует.

Я рассуждаю прагматично: будут ли остальные команды демотивированы. На мой взгляд — будут.
Оппоненты же либо игнорируют этот вопрос, либо максимум рассуждают о том, должны ли остальные команды быть демотивированы. Но в работе руководителя важно не идеализированное как «должно быть», а только прагматичное «как будет».

Кто-то пытается предусмотреть последствия поступка, а кто-то — придумать оправдания. Это и отличает хороших менеджеров от плохих.

В целом, данных автор дал недостаточно, но я могу додумать всего 3 варианта:

1) Стартап — мотивация в виде премий за успех не нужна, т.к. эту роль уже выполнят опционы.

2) Бодишоп — все работают как обычные наемные работники, ни успех, ни провал продукта прямо не влияет на ЗП/премии. Собственно в бодишопах вклад наемных работников в успех продукта невелик, поэтому премировать за успех — глупо.
Бодишоп решил мотивировать соблюдение сроков — это прекрасно, но к премиям за успех это отношения не имеет.

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

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

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


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

Не у меня, а в задаче. Представлять не обязательно — в "Мифическом человеко-месяце" Брукса все уже представлено.

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

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

Это не мнение, а исходные данные задачи.


Вы готовы взять на себя ответственность утверждать, что абсолютно все члены других команд мыслят также как и вы, и никто не будет демотивирован?

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

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

Стоит ли эта демотивация той пользы, которую даст премия? В общем случае — скорее нет, ибо так уж люди устроены, что демотивация у них происходит намного легче и эффект имеет гораздо более выраженный. Получить условные +10% к производительности одной команды и -5% к производительности всех других команд, наверное принесет больше вреда, чем пользы.
Стоит ли эта демотивация той пользы, которую даст премия? В общем случае — скорее нет, ибо так уж люди устроены, что демотивация у них происходит намного легче и эффект имеет гораздо более выраженный. Получить условные +10% к производительности одной команды и -5% к производительности всех других команд, наверное принесет больше вреда, чем пользы.

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

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

Если какое-то ваше действие демотивирует 10% ваших сотрудников, то для компании из 5 человек — это ноль. А для компании из 200 человек, это уже 20.

Поэтому в общем случае, действия, демотивирующие процент от общего числа сотрудников, должны исключаться. Выдачу премии второй команде я отношу именно к таким действиям. Оно мотивирует ограниченное число людей, и демотивирует какой-то процент от общего числа сотрудников. Если у вас в компании уже идет счет не на людей, а на команды, то подразумевается что она уже не маленькая, и вреда скорее всего будет больше.
Угу, именно что другое представление о коллегах. Видимо потому, что в других коллективах работали.
UFO just landed and posted this here
Вопрос поставлен неправильно. Правильный вопрос, который задаст себе грамотный руководитель: могу ли я быть уверен, что остальные об этом не узнают? Если да (что маловероятно), то пожалуйста, выдавайте прению.

Ну а вообще, сам факт получения премии сотрудники обычно не скрывают, в отличие от, например, размера зарплаты. Т.е. узнают в обычном разговоре на обеде или в курилке. Конечно, если команды у вас полностью изолированы друг от друга, то никак и не узнают. Но такое бывает крайне редко.
UFO just landed and posted this here
Статус секретности носит сам факт получения премии, или ее размер? Если первое, то я удивлен.
У меня опыт был противоположный: меня например когда-то премировали за некие заслуги, и старались этот факт сделать максимально публичным для остальных, дабы они чувствовали, что за хорошую работу можно получить вознаграждение.
Может быть и первое. Чтобы не было обидно тому, кто старался, но премии не заслужил.

Одному пришла в голову крутая идея, другому нет. С одной стороны наградить надо (человек реально спас ситуацию), а с другой стороны, крутая идея — это больше везение.
UFO just landed and posted this here
Затем, что иначе премии начинают получать те, кто улыбаются начальству, а не те, кто хорошо работает.

Тут есть два ответа.

  1. И чем это плохо? Если я веду группу в поход — я предпочту иметь с собой рядом тех, кому я могу доверить свою жизнь. А не тех, кто быстрее ходит и больше груза несет. Особенно это важно при ночевках в -25 в палатке без печки. Так что есть компании, где личностные качества важнее объективных показателей.
  2. Вы как-то очень хорошо помните времена СССР и считаете, что начальство заведомо не заинтересовано в успехе фирмы. На самом деле у фирмы есть владелец, он заинтересован в прибыли. Есть руководство, подобранное этим владельцем и тоже заинтересованное в прибыли. Если политика руководства не максимизирует прибыль — руководство снимается. Ну или фирма разоряется.


Так… кажется я догадался — вы работаете в госсекторе. Блин… я забыл, что он ещё существует. Да, в госсекторе злоупотребления возможны.
Ваши команды вам перестают доверять, когда вы так себя ведете.

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

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


Можете сколько угодно тыкать им в лицо ТК РФ, люди «творческих профессий» это лицемерие не потерпят

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

Кому-то пообещали премию за сроки, в за день до выдачи премий правила переписали и выдали ее тем, кто сроки сорвал

Главное — что премию за соблюдение сроков выдали. А за что выдали ещё — не интересно.

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

УПС! А это вы откуда выдумали? С чего вы взяли, что кто-то премию не получит? У нас нет выбора — премию или первой команде или второй. У нас есть выбор премию и первой команде и второй. Или только первой.

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

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

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

Но вы правы в том, что давать или не давать премию зависит от того, насколько действия персонала соответствуют целям владельца фирмы.
В нашем случае это не просто «успешный продукт», а «успешный, но более поздно выпущенный продукт», насколько я понял ситуацию.
Так что пример очень простой — стартап. Есть очень ограниченное количество инвесторских денег, и если к моменту, когда они кончатся, не будет продаж, компания погибнет. И будет неважно, что успешный продукт почти-почти создан.
Да и вообще любая ситуация, в которой владельцу нужен стабильный cash flow, подойдёт. Например, если у него ипотека
Если есть MVP и продукт частично готов — просто идет второй раунд инвестиций. Но это странный такой стартап, у которого уже есть другой продукт и команда, работающая над ним. То есть это совсем не стартап.

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

Некий репутационный урон от задержки есть. Но к задержкам программистов все привыкли.

У меня были мысли про космос, где продукт должен быть готов к запуску. Ну или про АСТУП. Но там не бывает массовых продаж.

Чем грозит задержка в АСУТП
Цементный фильтр — это огромная дура на четырех ножках. Под ней — рабочие места четырех человек. Договор подписали поздно, фильтр смонитировали и решили запустить без автоматики. В итоге фильтр наполнился цементной пылю… и упал. Один был в туалете, один в курилке, двое удрали из под падающего фильтра.

При этом — срыва сроков со стороны разработчиков не было. Ни одной подписи разработчиков. разрешающей эксплуатацию без автоматики — не было. Прошляпили контроль фильтра — сами заводчане.

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


Но это все заказные и полузаказные разработки. Они известным условиям задачи не соответствуют.
Если есть MVP и продукт частично готов — просто идет второй раунд инвестиций.
И все же, может такое быть, что инвестиций дальше привлечь не удается. Или пан, или пропал. Так что пример вполне валиден, хотя, наверное, и встречается редко.
И инвестиции привлечь не удалось и MVP (+ уже сделанное) никому не продать и кредит не взять и люди не согласны в долг работать и сам стартапер не хочет или не может в одиночку доделать и уже сделанное и не продать тому, кто доделает… Ну строго теоретически — возможно.

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

Чистый код, быстрые алгоритмы и качественное тестирование обычно вносят гораздо меньший вклад в успех продукта, чем грамотная стратегия продвижения, успешные продажи и фичи, в которых нуждается рынок.
Ну и что же «сейлзы/продактых/маркетологи/etc.» не обеспечили успех первой команды? Уже имеющийся на рынке продукт продавать проще, чем новый.

Не надо путать программистов с кодировшиками. Это ничем хорошим не заканчивается. 3% технического преимущества, которые выводят одни продукты в лидеры, а другие в аутсайдеры — делают именно программисты.
Вы как-то очень хорошо помните времена СССР и считаете, что начальство заведомо не заинтересовано в успехе фирмы. На самом деле у фирмы есть владелец, он заинтересован в прибыли. Есть руководство, подобранное этим владельцем и тоже заинтересованное в прибыли. Если политика руководства не максимизирует прибыль — руководство снимается. Ну или фирма разоряется.

Вы несколько наивны, если думаете, что в рыночной экономике выживают эффективные и честные компании. На самом деле это в большей степени касается мелкого, иногда среднего бизнеса. В крупном бизнесе внутри компаний нередко творится полный СССР. И ничего, они так нормально работают, десятилетиями, а некоторые столетиями. Когда между владельцем и конечным исполнителем лежит десяток уровней управления, интересы владельца до низов не так уж часто доходят.
Вашими устами да мед пить. :-) Примерно 2000ый год, переговоры с дочерной компанией НорНикеля шли примерно так. В пятницу письмо «а пришлите нам»… ну в общем там неделю документы делать. Шеф напрягся, за выходные сделал. В понедельник — выходит очередная разгромная статья про их олигарха. И они замолкают на 3 месяца. Потом опять активизировались. Опять статья — и опять пауза.

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

Примерно такое же впечатление и от Северстали. Их не трясло, но каждую копейку считали как скруджи. По каждому варианту решения надо было делать обоснование — так дороже, но выгоды такие. Так дешевле, но будет хуже по таким-то параметрам. Хорошо хоть технические доводы они хорошо понимают.

P.S.Это вот моя предыдущая работа.
И чем это плохо?
Вы серьезно? Например тем, что это не соответствует целям компании. Об этом можно догадаться по самому факту введения этих правил.

На самом деле у фирмы есть владелец, он заинтересован в прибыли. Есть руководство, подобранное этим владельцем и тоже заинтересованное в прибыли. Если политика руководства не максимизирует прибыль — руководство снимается.
У вас как всегда абстрактное идеальное руководство, которое не допускает ошибок, и которому правила не нужны.

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

А ваш вариант, где идеальные менеджеры оценивают сотрудников уже пробовали в Microsoft. Торжество человеческого фактора и руководства заинтересованного в прибыли. Думаю всем известно насколько эпичный был фейл.

Так… кажется я догадался — вы работаете в госсекторе. Блин… я забыл, что он ещё существует.
Абсолютно мимо.

Да, в госсекторе злоупотребления возможны.
У вас, как у любого идеалиста, какой-то черно-белый мир. Госсектор, где злоупотребляют, и все остальное, где все белые и пушистые. Удивлю вас: злоупотребления бывают везде, даже в самых лучших компаниях. Даже мировые лидеры типа гугла/фейсбука постоянно ищут как бы сделать правила получше. Они бедные и не догадываются что все правила можно отменить и отдать все на откуп абстрактному идеальному руководству. Сферическому в вакууме.

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

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

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

Как я понимаю, вам в подобной ситуации сделали выговор за подрыв авторитета.
Вы себе выдумали какой-то фантастический образ оппонента: госсектор, авторитеты, выговоры… Вообще мимо кассы.

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

Вы плохо читали условия. Решение о выплате или невыплате премии второй команде делает тот же менеджер, который и придумал правило.

У вас как всегда абстрактное идеальное руководство, которое не допускает ошибок, и которому правила не нужны.

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

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

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

Я правильно понимаю, что тогда победил лично ваш гонор?
Решение о выплате или невыплате премии второй команде делает тот же менеджер, который и придумал правило.

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

Ну на том же уровне принятия решений. Иначе это вопрос о лояльности нижестоящего менеджера к вышестоящему менеджеру. А это уже не менеджмент, а политика.

А у политических вопросов могут быть и другие ответы. я вот не пойду против мнения владельца фирмы. То есть пойду, но в чисто технических вещах, где я разбираюсь лучше. А в менеджменте она более компетентна. Так что будет останавливать то, что «а вдруг я неправ?» Переубедить — попробую. Но не более того.

Так что проще считать, что политики в выборе решения нет.
Бывают ситуации, когда подчинение важнее всего остального. В армии, например
Скорее уж авионика, чем армия. Но и у разработчиков военной авионики — тупого солдафонства нет.
Вы плохо читали условия. Решение о выплате или невыплате премии второй команде делает тот же менеджер, который и придумал правило.
Вы о чем вообще? Я сказал что плохо, когда премии получают те, кто подлизывается к начальству, а не те, кто хорошо работает. А вы сказали что в этом ничего плохого нет. Даже не вижу смысла обсуждать этот вопрос, оставайтесь при своем мнении.

Не, если правила ошибочны — лучше их отменить совсем.
Да ну? Где? Про отмену правила речь не шла.
No comments.

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

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

Кто-то решил закрыть проект и потерять затраченные деньги просто потому, что ему не подчинились?
Не думаю что проект закрыли, просто наняли другую команду. А что вас удивляет? Человек платит деньги и ожидает результат, а «умные» менеджеры постоянно выдают абсолютно не то, что он просил. Человек решил что он быстрее достигнет желаемого результата наняв кого-то другого, я его прекрасно понимаю.

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

В некоторых условиях — это не плохо. Есть такие должности, где личная преданность — важнее других качеств. Например — секретарь или помощник руководителя. Можно взять умного, но он будет вести свою политику. А можно взять такого, кто будет на 100% вести политику руководителя.

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

Понятно. Вы перепутали отмену правил с отменой выплаты по старым правилам. Удаление объекта класса не означает аннулирование всех контрактов, в которых участвовал этот объект до удаления.

И я в сотый раз говорю — это пагубная практика, которая демотивирует людей. Она способствует фаворитизму, от которого люди как раз пытаются уйти, введением объективных правил.

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

А фаворитизм… В хорошем случае у начальника все чувствую себя фаворитами. Один крут в одном, другой — в другом…

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

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

Брукса почитайте. Это даже дольше, чем начать проект с нуля.
В некоторых условиях — это не плохо. Есть такие должности, где личная преданность — важнее других качеств
Зачем вы уводите разговор в рассуждения о некоторых условиях и некоторых должностях? Речь идет о конкретном примере.
Более того, лизать пятую точку — это не то же самое, что преданность, вы подменяете понятия. В общем случае, награды за подлизывание — это плохо. Это правда нужно объяснять?

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

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

Брукса почитайте. Это даже дольше, чем начать проект с нуля.
Ха-ха. То есть вы утверждаете что в абсолютно любой ситуации менять команду нельзя? Где же это вы нашли такое догматичное мышление у Брукса, который как раз говорил о no silver bullet?
Более того, лизать пятую точку — это не то же самое, что преданность, вы подменяете понятия.

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

Все фаворитами быть не могут просто по определению.
Учитесь понимать русский язык. Быть — не могут, а чувствовать — могут. Это как 20 любовниц Казановы и каждая считает себя самой любимой.
То есть вы утверждаете что в абсолютно любой ситуации менять команду нельзя?
Можно. Но это затянет сроки сильнее, чем начать проект с нуля.

Это как с грибами — все грибы есть можно, но некоторые ядовитые — только один раз.
Мягко говоря не представляю лизоблюдов в программировании.
Что за глупость? А в какой области представляете, в кулинарии что-ли? Лизоблюдство — это область человеческих отношений, оно от профессии не зависит вообще никак. Может быть в любой сфере где есть хоть какая-то иерархия.

это затянет сроки сильнее, чем начать проект с нуля.
Серьезно? Абсолютно любая команда в абсолютно любой ситуации сделает абсолютно любой проект быстрее, просто потому что она начала первой? Вы как-то неправильно Брукса читали.
В дизайне сайтов — легко. Кто сильнее заказчика облизал — тот сайт и круче. Ибо объективных критериев почти нет.

А в инженерии — хватает объективных критериев. Да и мозги у технарей иначе закручены. Ну вот вам ithappens. Поищите истории про лизоблюдов. Про всех есть, а про лизоблюдов — нету. Ибо зачем писать о том, чего нет.

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

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

Могу ещё добавить, что разработка второй командой проекта с нуля будет быстрее, чем первой. Потому что вторая команда не будет повторять ошибки первой, а сразу пойдет более верным путем. Ну разумеется, если первая команда не ушла вместе с know-how.
В дизайне сайтов — легко. Кто сильнее заказчика облизал — тот сайт и круче.
Какой еще дизайн сайтов, какие заказчики, вы о чем? По вашему идет речь о конторке которая делает сайты «под ключ»? Очередная ваша нелепая догадка?

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

А в инженерии — хватает объективных критериев
Как же легко вы меняете свою позицию ради демагогии. Вчера у вас инженерия была творческой работой, для оценки которой нужен человеческий фактор, а сегодня в ней уже нашлось полно объективных критериев. Может все-таки определитесь?

Кстати, где ж вы раньше-то были со своими объективными критериями? Могли бы тому же Microsoft миллиарды долларов сэкономить, а то они балбесы без вас больше 10 лет мучались.

смена команды на проекте затянет сроки сильнее, чем начать проект с нуля
Абсолютно на любой точке, верно? И где ж вы у Брукса такие догмы находите…
Вы серьезно идете на сайт со смешными историями чтобы выяснить бывает ли в IT-компаниях лизоблюдство?

Да ноль проблем, попробуйте найти на любых других сайтах.

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

А понять слабо?

У меня дочка участвует в соревнованиях по графическому дизайну. Более чем творческая работа. Но я смотрю на таблицу с оценками судей и вижу, что оценки-то сходятся. Да плюс-минус пара баллов, но в общем-то оценка отдельного судьи не сильно отличается от итоговой. А это означает — объективность критериев.

Абсолютно на любой точке, верно? И где ж вы у Брукса такие догмы находите…

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

А!!! Вы опять не то прочли!!! Смысл не в том, что замена команды никогда не ускорит проект. Смысл ровно в том, что я сказал: "это затянет сроки сильнее, чем начать проект с нуля".

Объясняю на пальцах. Старая команда работала 3 года и собиралась работать ещё 2 года. Взяли новую, в 10 раз более сильную. Она напишет с нуля проект за год. Или за полтора года — доделает старый.
Если строго — то кроме нулевой и чуть удаленной от нуля.
Чуть удаленной от нуля — это по вашему строго?

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

Взяли новую, в 10 раз более сильную.
Ой, а расскажите заодно как вы «силу» команды меряете. Так чтоб можно было замерить разницу аж в 10(!) раз.

А то я подозреваю у вас как в анекдоте:
— Ты сильный программист?
— Вроде да
— Тогда будешь перетаскивать компьютеры
Вот человек и решил, что команда, которая каждый месяц демонстрирует не то, что он просит — низкой квалификации.

Так за высокую квалификацию — платить надо больше.

Ой, а расскажите заодно как вы «силу» команды меряете. Так чтоб можно было замерить разницу аж в 10(!) раз.

Количество строк кода в проекте в момент окончания тестирования делим на человеко-дни. Это при условиях одинаковой плотности ошибок в финальном коде, одинаковости языка и примерно равного объема проектов.

Графики зависимостей у кого-то были. У Майерса, что ли…
Количество строк кода в проекте
Эх, видимо вы все-таки строитель, от software очень далеки. Ну спасибо, хоть посмешили. Сначала философствовали о нетиповых задачах, а потом стали разработчиков мерять строками кода.
Если вы прочтете определение целиком, то поймете, что оно релевантно. Кстати, типичное число — 10 отлаженных строк в день на больших программах при работе без IDE (с IDE повыше). Да, можно и написать и 2 тысячи строк. Но отладка, доделки, переделки, время на обдумывание алгоритмов, командировки на объект…

Ну как пример. 135 тысяч строк кода, 10 человеколет, то есть 2470 рабочих дней — 55 строк в день.

А задач более чем не типовая, работает 15 лет без ошибок в режиме 365 на 24 при цене хорошего сбоя 35-40 тысяч долларов.

Знаете, любой ученый может стать академиком. Только одну для этого требуется 30 лет, а другому — 300. Точно так же любой программист за пару тысяч лет напишет и отладить сколько угодно сложный код.

Так что производительность — вполне себе мерило.

Особенно — на сложных, нетиповых задачах.

P.S. Если бы у меня в той команде был не один будущий CTO JetBrains, а несколько — было бы 3-5 человеко-лет, а не 10.
Какой же вы все-таки дилетант.

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

Вопрос: нафига вам в этой ситуации вообще мерять строки кода? Зачем вам еще какая-то метрика кроме затраченного времени?

Одна команда написала за месяц с кучей boilerplate кода, получилось 100,000 строк. Другая тоже за месяц, но уложилась в 10,000. По вашей великолепной метрике, boilerplate-команда в 10 раз «сильнее». Т.е. я оказался прав — силу команды вы меряете по тому, насколько сильно они нажимают на клавиши. Браво!

Если вам дали миллион кирпичей и сказали построить дом, то вы действительно можете мерять эффективность команды строителей количеством уложенных кирпичей в день. Но строки кода — это не кирпичи. Никто не выдает вам миллион букв, из которых нужно собрать код. Буквы, в отличие от кирпичей, денег не стоят и ресурсом не являются.

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

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

Ну с вами всё понятно. Дальше можно не продолжать. Если вы код и писали — то лишь на маленьких проектах. Про увеличение сложности, пропорциональное примерно квадрату количества строк кода — не слышали.

Одна команда написала за месяц с кучей boilerplate кода, получилось 100,000 строк.

Понятно. Про отладку и тестирование — не слышали. И даже не сумели прочесть то, что я написал.

Не позорьтесь уж… Написать можно все, что угодно. Но надо ещё отладить. Первая команда с отладкой и тестированием провозится год. Вторая — месяц. Что будет в итоге? По производительности победит вторая команда.

Знаете, Маяковский был поэтом, а не программистом.
Про увеличение сложности, пропорциональное примерно квадрату количества строк кода — не слышали.
Так зачем же вы поставили кол-во строк кода в числитель? По вашей метрике, чем больше строк кода, тем лучше. Дошло наконец?

Не позорьтесь уж… Написать можно все, что угодно. Но надо ещё отладить. Первая команда с отладкой и тестированием провозится год. Вторая — месяц.
Я ведь написал, следуем вашему фантастическому примеру. Обе команды оттестировали за одно и то же время, на выходе получили примерно одинаковый продукт. По вашей метрике первая команда получается в 10 раз сильнее, ведь у нее в 10 раз больше строк кода.

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

Ух ты, какой мошенничество! Вы придумали нереальный пример, а потом приписываете его мне!

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

Плотность ошибок растет примерно как логарифм числа строк. Так что в 10 раз большей программе — ошибок будет в 23 раза больше. Ну и время и отладки увеличится почти пропорционально числу багов. Впрочем, время тестирования — тоже.

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

И я все еще жду ответа, где же должно находиться кол-во строк кода, в числителе или в знаменателе? А то вы сначала пишете одно, а потом гневно доказываете другое.
Попытайтесь понять отличия написанного кода от отлаженного. Если поймете — все встанет на свои места.
Попытался. И в моем, и в вашем примере подразумевается отлаженный код.

И все-таки, не уходите от ответа. Числитель или знаменатель?
Отлаженные за месяц 100 тысяч строк — это что-то из области приписок и халтуры. 10 тысяч в месяц — и то, очень фантастично.

Так что в реальном примере производительность более многословной команды будет ниже, чем у пишущей более кратко.
Что ж вы так боитесь ответить на вопрос? Ну хорошо, месяц вам не нравится, пусть любой другой промежуток времени. Сути это не меняет. Две команды, за некий промежуток времени показали одинаковый по функциональности и багам продукт. У одной получился boilerplate-код и 100,000 строк, у другой — 10,000 строк. Первая в 10 раз сильнее?

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

Вы приводите нереальный пример. Попробуйте сами написать одну задачу двумя способами. Длинным и коротким. Отладьтесь и отдайте тестеру на проверку. В длинном решении найдется больше багов. И займет оно большее время.

Так что ответ прост — первая команда сильнее. Но поскольку сильная команда не пойдет длинным путем, то получается, что пример нереален. Читайте Смалиана, он хорошо объясняет, что будет, если всесокрушающее ядро воткнется в несокрушимый столб.

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

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

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

Количество строк кода в проекте в момент окончания тестирования делим на человеко-дни. Это при условиях одинаковой плотности ошибок в финальном коде, одинаковости языка и примерно равного объема проектов.

А вас что, смущает, что человеко-дни зависят от N*ln(N), где N — число строк кода? Ну привыкайте, в математике и похитрее бывает. Вот вам полный текст очень полезной для вас книжки Смалиана.
Вы приводите нереальный пример.
Спасибо, это и требовалось доказать. Утверждение про команду, которая в 10 раз эффективнее сделали вы. Когда я попытался придумать пример такой команды, он оказался нереален.

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

А вас что, смущает, что человеко-дни зависят от N*ln(N), где N — число строк кода?
Зависят, как я понимаю, прямопропорционально, верно? Слабенький из вас инженер. Неужто вы и документацию так пишете? Тогда я не удивлен, что вы боитесь уголовной ответственности.

Итак, мы наконец-то получаем формулу: N/(N*ln(N)), которая эквивалентна 1/ln(N). Т.е. сила команды обратно пропорциональна натуральному логарифму из количества строк кода (с учетом следования остальным правилам, которые вы уже назвали фантастическими, но пока забудем об этом) Т.е. оказалось, что «человеко-дни» — это побочная величина, в формуле не участвующая. Зачем вы так безграмотно усложняете свои формулы? Предлагаю добавить в числитель количество членов команды, а в знаменатель количество количество рук деленное на два. Ну чтоб еще сложнее выглядело, вы же любите напыщенность.
UFO just landed and posted this here
  1. Считать надо человеко-месяцы, а не длительнось. Команда может состоять и из одного програмиста и из 10. На неготорых, хорошо распаралеливаемых задачах, команда из 10 человек в 7-8 раз сильнее команды из одного человека.
  2. Выдает — это что означает? Написал? Написал и отладил? Написал, отладил, прошел тестирование? Нужно третье, то есть время, затраченное до уменьшения числа багов ниже заданного уровня. А поскольку число багов зависит от длины кода как N*ln(N) выигрывать по времени (и силе) будут менее многословные команды.
  3. Вряд ли в 3 тысячи строк на хаскеле войдет выдача ошибок в человеческом виде. Похоже, что общим у них лишь основной функционал. Уж больно разница велика — в 30 раз.


Жду уточнений, тогда и посчитаем.
UFO just landed and posted this here
2) Нет, фишка в том, что время отладки линейно не будет. В лучшем случае n*ln(n), это такой полу-эмпирический факт, взятый из литературы.

3) Ещё есть фактор — одинаковый проект. Во всех функциях одинаковый. Помните у Брукса — комплексный программный продукт в 9 раз более трудоемок, чем программа? Из вашего расхождения в 33 раза по длине кода вытекает, что на хаскеле писали программу, а на С++ — комплексный программный продукт.

4a) Считаем мощности в ваших предположениях. У Хаскеля — 1000 строк в месяц, на С++ — 8.3 тысячи строк в месяц.
4б) Считаем мощности в моих предположениях. На хаскеле — 1 програмист, на С++ — 10. 1 тысяча строк на человека в месяц на хаскеле против 0.83 у С++.
4в) Добавляем, что на хаскеле — программа, на С++ — программный продукт. Разница в трудоемкости в 9 раз. 0.16 на хаскеле против 0.83 на С++

повторная реализация половины STL, велосипедный сериализатор в JSON, уйма копипасты и прочее счастье.

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

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

Так что при верном подсчете — победит команда А.
UFO just landed and posted this here
А если вы на С++ напишете в 3000 строк, а то же на ассемблере в 100000 строк, то у вас снова будет программа и комплексный программный продукт соответственно?

Да. С++ транслируется примерно 1 к 10, если не 1 к 6. Впрочем, бывают и очень тупые процессоры…

Откуда вы это взяли? Просто из-за разницы числа строк? Выглядит как притягивание за уши.

Угу, непонятно откуда разница в 30 раз.

У вас проверяющий эффективность потом ходит по всей кодовой базе и проверяет, что там действительно нужно было, а что — нет?

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

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

Давайте угадаю? Вы небось сайты делаете. Тогда от кодировщиков не зависит почти ничего, а от продажников — многое.

Вот только сайт — это не тиражный продукт. Другие объемы, другие сроки…
Сначала вы намекали на школу, потом посадили меня в госсектор, затем придумали какие-то выговоры за подрыв авторитета, после этого был мой гонор который на что-то там повлиял, затем я хотел быть типовым винтиком, а теперь оказывается я делаю сайты. Завязывайте уже с этим, не получается у вас угадывать. Вам личная неприязнь мешает мыслить адекватно.

Я создаю продукт, который, грубо говоря, позволяет управлять потоками товаров в определенной нише.
У него конечно есть веб-интерфейс, но назвать это деланием сайтов у меня язык не повернется.
Будет MVP — напишите статью. Ну если он будет, конечно.
Несколько лицемерно с вашей стороны просить написать статью, ЕВПОЧЯ.

А MVP, который приносит мне (пока) небольшие деньги — уже есть.
Но статью я если и напишу, то не о продукте, а о том, как в погоне за мнимыми миллиардами современные инженеры отказываются от миллионов. Построить элементарный бизнес на миллион сегодня уже не круто, все стремятся быть единорогами.
Это не лицемерие, это мое любопытство раньше меня родилось.

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

Ну всегда хочется сделать что-то чем можно гордиться, а не просто заработать деньги. Как сказал один шапочный знакомый: «в фирме у меня заработок был намного больше, чем в стартапе. Но если я бы упустил эту возможность — то все локти бы себе потом искусал». Уходил он из чего-то типа гугла или GE, могу уточнить, если надо.
всегда хочется сделать что-то чем можно гордиться, а не просто заработать деньги
А чем плохо просто зарабатывать деньги? Вообще-то, деньги люди дают только в обмен на что-то, что им нужно. Так что чем больше денег заработано — тем больше пользы человечеству принесено.
А чем плохо сделать себе имя? Оно ведь тоже в обмен на труд создается. Вот только зарабатывают многие, а имен — мало.
Да ничем не плохо. Я не согласен именно с общностью того утверждения, которое цитировал.
Ну общность она для определенной среды верна. Просто большинство программистов — из этой среды. Ну это как отсутствие женщин-программистов — вроде они и есть, но как морские свинки — или не совсем женщина или не совсем программист.

А сами разве не хотите известности? А какая тогда мотивация писать статьи на хабре? Вам ведь за это не платят?
И я в сотый раз говорю — это пагубная практика, которая демотивирует людей. Она способствует фаворитизму, от которого люди как раз пытаются уйти, введением объективных правил.

И я вдруг понял, кого мне ваши стоны напоминают. :-)

Зарисовки с натуры
Есть четверо детей. Точнее трое + годовалая. И из этих троих один — ну назовем его Д. Двое бояться потеряться и никогда не отбегут далеко от взрослого. Да нужно постоянно контролировать. Двое понимают, почему попасть игрушкой в друг друга это одно, а в малую — ну совсем другое. Д не понимают. Двое по просьбе делают нормальный чай или кофе, а Д залил растворимый кофе водой из крана. А что, по игре — нормально. А что жизнь — не игра, он не понимает.

Итог. Двое в фаворитах, Д в аутсайдерах. И любая похвала Д демотивирует.

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

Как думаете, что будет, если взрослые введут правила и будут их придерживаться? А будет совсем плохо, Д просто не будет вылезать из угла. У взрослых хватит ума, чтобы придумать нужные им правила. А вот возможности что-то простить Д — уже не будет.

А было бы детей не трое, а полный отряд — было бы 25 фаворитов и 5 атусайдеров. Увы, дети не сотрудники, их не принудишь написать «по собственному».

Решается это так. На отряде — два разных вожатых. И аутсайдеры одного оказываются в фаворитах у другого. А вот если нашлось чудо, которое стало аутсайдером у обоих, то выход один — менять ему отряд.

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

Не, это ровно игра по правилам. Давайте угадаю? Законы вы не читали. Ни один суд — не выиграли. Отличие прав от обязанностей — не понимаете.

А в любых правилах есть огромный зазор между «имеет право» и «обязан». Иначе бы вы вас приводили в отделение за любой разговор на повышенных тонах.

Другой момент, что трактуются эти правила в пользу начальства. Ну кто пишет правила — тот их и трактует. И выиграть «по правилам» намного сложнее, чем без них.

Вот вам замечательный пример, какая жуть происходит, если правила нельзя нарушить.
Вы, простите, какую-то чушь написали. Вы не понимаете что такое фаворитизм. И в очередной раз хамите (это я про «стоны»).

какая жуть происходит, если правила нельзя нарушить
А я не говорю, что правила никогда нельзя нарушать. Я говорю о том, что нужно уметь увидеть последствия этих нарушений, а не нарушать просто потому что захотелось.

Даже автор поста сам соглашается, что премия второй команде демотивирует кого-то из членов других команд.

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

1) а мы на самом деле правила не нарушили, это их проблемы, что они неправильно поняли наши правила
2) они просто завистливые, их даже нужно демотивировать, им это пойдет на пользу
3) зачем вообще думать о последствиях, ведь выдать премию — это же справедливость!
4) мне приятнее верить что у нас в компании работают люди, которые не будут демотивированы такими вещами

Заметили что-то общее у всех этих аргументов? Они все носят личностный и эмоциональный окрас. Они не оценивают последствия выдачи премии, а придумывают оправдания. Руководитель, принимающий бизнес-решения на основе эмоций и оправданий — дилетант. Которым я вас уверенно считаю. В будущем хотя бы научитесь вести диалог без хамства.
Интересно, при рейдерском захвате, сколько человек уйдет вслед за нашим гендиректором? Минимум — 80%, максимум — все, кого захочет взять. На новое место, с понижением зарплат… Более того — уйдет и 80% заказчиков.

Такая вот сила «личностного и эмоциональный окраса».

И да, мне намного важнее справедливость в отношении, кто принес фирме успех, чем какие-то абстракции.

Вторая команда сделает фирме ещё один успешный продукт. А первая, что работает на саппорте… Первая, в худшем случае заменяется.

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

Мне не кажется, что настолько простая идея нуждается в оправдании.

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

Кстати, я бы кроме премии, ещё и на сайте вывесил авторский коллектив, работавший над программой. Да, это приведет к активному переманиванию. Но плюсы от поощрения — больше.
при рейдерском захвате, сколько человек уйдет вслед за нашим гендиректором?
Я, к счастью, не работаю в сферах и странах где возможен рейдерский захват, поэтому для меня этот критерий выглядит абсолютно дико. Строить компанию, готовясь к рейдерскому захвату — это не для меня.

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


Вы увидели причинно-следственную связь в этих двух пунктах? Я — нет. Я допускаю, что она была, но из утверждений, сделанных автором, она никак не выводится. Поэтому ваша «справедливость» пока что очень субъективна, она основана на эмоциях и домыслах. А в бизнесе этому не место. Тот, кто собирается вершить подобную «справедливость», очень опасен.

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

К вашему сведению, лучшим способом мотивации я считаю опционы. Я предлагаю делиться с сотрудниками не деньгами, а владением компанией. Со мной всегда так поступали, и меня это вполне устраивало.

у вас и разработчики следят друг за другом — сколько кому премии дали
Очередные ваши домыслы. Не надоело фантазировать?
Строить компанию, готовясь к рейдерскому захвату — это не для меня.

Тогда не используйте инвесторов и не раздавайте опционы. Как только у компании несколько владельцев — возможна ссора между ними и раздел компании или переход управления в другие руки. 20-30% в чужих руках — достаточно для того, чтобы было проще создать новую компанию, чем ругаться с совладельцами.
Вы увидели причинно-следственную связь в этих двух пунктах? Я — нет. Я допускаю, что она была, но из утверждений, сделанных автором, она никак не выводится.
Да, разумеется. Если связи нет — до нет и дилемы награждать или нет. При отсутствии связи если и премируем, то продажников. Собственно можете получить подтверждение от Bonart, что связь есть.
К вашему сведению, лучшим способом мотивации я считаю опционы. Я предлагаю делиться с сотрудниками не деньгами, а владением компанией.
Спорно. Раздавать дивиденты или вкладываться в развитие — это решение владельца. А если есть опционы — при вложении в развитие будет конфликт интересов. Плюс возможность захвата, если кто-то решит скупить опционы.

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

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

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

Вопрос в том, как померять, кто внес больший вклад в успех, инженеры или, допустим, продакт менеджеры? Как оценить вклад каждого инженера?

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

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

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

Безусловно есть крайне технологические компании, где это не всегда будет верно. В успех какого-нибудь Unreal Engine разработчики действительно внесли огромный вклад, и именно они наверняка заслуживают разнообразные премии. Но такие примеры достаточно редки, чтобы не учитывать их «по умолчанию». По умолчанию, разработчик — исполнитель, и премию получает именно за качество исполнения (например сдачу в срок), а не за коммерческий успех продукта.

Тот, кто хочет получать премию за коммерческий успех, должен быть готов получать штраф за коммерческий провал. Такой подход давно изобретен, и вполне работает. Называется «опцион».
В успех какого-нибудь Unreal Engine разработчики действительно внесли огромный вклад

Мда, уровень понятен. Уголовной ответственности за ошибки — нет. Наукоемкость если и есть, то немного.

А вот вам реально сложная работа — система прочностных расчетов зданий и сооружений «Ладога». По ней считали цеха в сотне проектных институтов СССР. В основе — докторская диссертация по сопромату будущего почетного академика архитектуры. Тимлид — тоже сопроматчик, кандидат наук. Не помню, какие были сроки за ошибку в программе во времена ССР — сейчас это до 5 лет принудительных работ. Мне тогда 17 лет было, я на этом проекте техническим писателем был.

В основе нынешней работы лежит как минимум кандидатская нашего гендиректора. И задание иногда выглядит как «вот научная статья, реализуй это в коде». :-)

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

Вы не понимаете главного — или исполнители (кодеры) или инженеры (программисты). Вместе — не сочетается.

Такой подход давно изобретен, и вполне работает. Называется «опцион».

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

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

А в 17 лет очень по-разному пишут. Есть такой yole из Jet Brains. Так вот, он в 17 лет был моим сотрудником на двух проектах. Сначала — немного тестером на Ultima-s (но его быстро утащили в девелоперы на SQL), потом девелопером на Delphi. В обоих случаях уровень его компетентности был такой, что лучше бы ему быть начальником, а не мне.

Дело в том, что не все программирование на первой курсе начинают учить. Собственно у Звенигородского был даже восьмилетний девелопер. Кстати, это не единственный случай в мире.
Ну и как, часто вам в СССР давали премии за рекордную прибыль? Кстати, ошибки сопроматчиков часто вскрываются лет эдак через 20. Как с премиями быть? Сначала дать, а через 20 лет — забрать и расстрелять?

Мда, уровень понятен. Уголовной ответственности за ошибки — нет
Стоп, вы же сами были против ответственности за провал продукта. Я вам сразу сказал — хотите премию за коммерческий успех, будьте готовы к ответственности за провал. Опять определиться не можете?

Тот факт, что премию решили давать за сроки, а не за коммерческий успех, очень явно намекает на то, что команда — это именно исполнители.

сейчас это до 5 лет принудительных работ.
Сколько пафоса. А по ссылке — «Нарушение правил безопасности при ведении горных, строительных или иных работ».
Мы с вами точно на IT-ресурсе, а не на форуме строителей?

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

Во-вторых — под пул опционов обычно выделяется порядка 5-10%. Если вы уже труситесь от страха отдав такой процент компании своим сотрудникам, то лидер из вас не очень.

Во-третьих — вы же только что говорили о единомышленниках, которые пойдут за лидером в огонь. Но выдать им опционы вы боитесь, т.к. возникнет «конфликт интересов». Очередное ваше лицемерие.

В-четвертых, у вас типичное совковое мышление. Вы по умолчанию рассматриваете инвестора как богатого олигарха-злодея, который хочет вас обокрасть и отобрать у вас компанию. А в жизни наоборот. CEO подчиняется совету директоров, потому что это защищает компанию от его неадекватных действий. Потому что есть руководители, вроде вас, которые действуют эмоциями и вершат «справедливость», вместо того чтоб действовать в интересах компании. То, что в ваших глазах выглядит как рейдерство, на деле обычно оказывается благом для компании. Представляете, недавно злые акционеры заставили одного СЕО покинуть свой пост. Почему же никто не кричит о таком масштабном «рейдерстве» на 60 млрд долларов?
Уголовной ответственности за ошибки — нет
Стоп, вы же сами были против ответственности за провал продукта.

Мда, у вас точно проблемы с русским языком. Может перейти на английский? Куча успешных продуктов содержит ошибки. Сколько ошибок в Windows — думаю, что сами знаете. Так что может быть и успешный продукт с кучей ошибок и не успешный продукт без ошибок (насколько я помню в своей время Дейкстра или Хоар математически верифицировали ядро некой ОС).

А по ссылке — «Нарушение правил безопасности при ведении горных, строительных или иных работ».
Мы с вами точно на IT-ресурсе, а не на форуме строителей?

Точно. Уголовная ответственность распространяется и на авторов софта. Редкость, конечно, но бывает.

Вот реальный случай. Коллега делал систему, аналогичную описанной в моей статье. Во время установки системы погибли люди. И ему пришлось долго доказывать с документами, что в момент гибели людей система ещё не была запущена. А была бы запущена — встал бы вопрос об ответственности авторов системы.

Во-первых, опционы не могут продаваться «на сторону»

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

Если вы уже труситесь от страха отдав такой процент компании своим сотрудникам, то лидер из вас не очень.

Остапа опять понесло? Повторюсь, я не владелец фирмы. И единственное применение опциону вижу в превращении его в деньги. Ибо мне выгодно, чтобы средства шли в развитие, а не в девиденты.

Во-третьих — вы же только что говорили о единомышленниках, которые пойдут за лидером в огонь. Но выдать им опционы вы боитесь, т.к. возникнет «конфликт интересов».

Да, я считаю что опционы — обман. Опцион — это не премия, а наоборот, это возможность для владельца компании содрать с работника лишние деньги, продав ему акции по опциону. А далее работник в западне. Как владельцу акций ему выгодно доить корову посильнее. Как работнику — развивать фирму.

А уж в условия РФ, когда уставной капитал у многих по 10 тысяч рублей, опционы на 50-100 рублей — обман в кубе.

Как говорится — у нас с банком договор: он не торгует семечками, а я не даю кредиты.

Представляете, недавно злые акционеры заставили одного СЕО покинуть свой пост.

А вы в курсе, что потом Джобса уговорили вернуться обратно? А без Джобса доля Aplle на рынке упала в 4 раза?

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

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

А что такое компания? Счет в банке? Бренд? Станки и компы? Помещение? Компания — это прежде всего люди, которые в ней работают. Команда. То know how, которое у этой команды есть.
И опять вас подводит плохое знание русского языка. Погуглите «торговля опционами» — узнаете много нового. Про то, что опционы бывают биржевые, что есть котировки и так далее.
Это вас подводит полное незнание матчасти. Вы полнейший профан, и явно палитесь что свои «знания» черпаете гугля в яндексе. К сожалению, гуглите не очень успешно.

Даже идиоту понятно что в данном контексте речь идет об employee stock option — по-русски это вроде как называется опцион эмитента. Обратите внимание, опцион эмитента — именной. Ни о какой тороговле ими на бирже речи не идет. Биржевые опционы — это совершенно другой инструмент, хотя и функционирует схожим образом. Пожалуйста, выключите свой поучительный тон когда говорите о вещах, в которых вы полный ноль.

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



А далее работник в западне.
Какой кошмар. Бедному работнику приходится работать ради успеха компании, а не только просиживать штаны за зарплату. Вот сволочи, а, работать заставляют. Нет чтоб просто премии за успех продукта дввать. Но не штрафовать за провал. Ведь в любом успехе ключевую роль всегда играют разработчики. А в провале — какие-нибудь, эээ, менеджеры. Даешь больше прав и меньше ответственности!
Бедному работнику приходится работать ради успеха компании

И бедный и богатый работник работает ради успеха компании. Не знали? И получает за это зарплату.

Штрафы за провал — да ради бога. я уже рассказывал, как это устроена на Северстали. Премия равна окладу, 100% премии снимается за простой 3 часа в месяц. И не с работника — со всей службы.

Знаете, как люди работают, чтобы у них было «Ни минуты простоя за год»? 3 дня идет ППР (планово-предупредительный ремонт). И все это время автоматчики (программисты контроллеров) на работе.

Во время ППР происходит смена программ и модернизация оборудования. На его выходе — есть 2 часа планового брака. Это время на отладку на живом стане. Не успел — откатываешь все назад.

И вот ППР закончился и отличный инженер подходит к начальнику: «Стан поехал, все в норме. Можно я пойду спать?»

И так — каждый месяц. Ладно мы, у нас командировка, мы и ехали чтобы не спать. Для нас это всего несколько раз. А у заводчан — ППР каждый месяц.

А вы предлагаете их наказывать каждый раз, когда Россия ссорится с США? За заградительные пошлины, за колебания курса доллара?

Если ваши работники вас читают — им уже давно понятно, что вы за человек.
А вы предлагаете их наказывать каждый раз, когда Россия ссорится с США? За заградительные пошлины, за колебания курса доллара?
Вы правда думаете, что пример автора был о сталелитейных заводах или о строительных компаниях? Точно вкладки не попутали?

Подозреваю, что реалии автора сильно отличаются от вашей Северстали, зачем вы постоянно приводите ее в пример? Более релевантного опыта у вас нет, а поумничать хочется? Или Северсталь уже стала ИТ-компанией, которая производит не сырье, а интеллектуальную собственность?

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

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

Знаете, там почти нет рабочих. Ну есть уборщицы, есть крановщики. А все остальные — инженеры.

Не знаю, какой был уровень проникновения банковских на западе в 2000 году, но в Череповце он был 100%ный. Ночью в ларек заходишь, а тебе «денюшка али карточка»? Москва и Питер до сих пор не добрались до уровня Череповца 2000 года.

Так что не IT, но очень высокотехнологичная.

Но, черт возьми, какое отношение это все имеет к хабру?

Интересно понять, у кого не стоит работать ни при каких обстоятельствах.

Опыт у меня намного больше, чем рассказываю, но… я всегда работал там, где к людям относятся как к самому ценному ресурсу компании.
UFO just landed and posted this here
«можно я пойду спать» раз в месяц?

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

Про заказчика. Но при установке системы — режим был тот же. Ибо те же 2 часа на отладку. Закончились они — и или система работает или откат и перерыв на месяц, до следующего ППР. Горжусь тем, что откатов не было.
А как сам думаешь, сколько нужно набрать программистов, чтобы они могли спать во время отладки кода?

На агрегате — 9 тысяч датчиков и тысяча выходов. Получая модернизация, то есть на ППР меняется и железо и софт. При всем желании промоделировать поведение железа во всех деталях невозможно.

Поэтому на ППР меняется железо и сразу начинается отладка. На ППР пока стан стоит — можно смотреть отдельные кусочки. А два часа планового брака на старте — это время для комплексной отладки. Так что трое суток ППР — на вес золота.

А спокойно спит — дежурная смена автоматчиков. То есть вполне официально — спит или книжки читает. Но по сирене — сразу просыпается и устраняет проблемы.

Думаю, что понятно, что в дежурной смене — люди попроще, они работают уже с отлаженным кодом. Смены у дежурных — 12часовые, но им так удобно. Они меня долго убеждали, что 12 часов через сутки — удобнее, чем 8, но каждый день.

Да, это заказчики. Но мы в командировках жили в том же режиме. То есть на отладку нашей системы — те же 2 часа в месяц.
Видимо TimTowdy путает сложный проект с объемным. Могу себе представить какой-то большой, но простой сайт, где с версткой справится любая команда из юниоров. Что типа сайта со страничками на всех учеников школывоспитанников детдома. Или очень простая, но объемная SCADA.

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

20-30% в чужих руках — достаточно для того, чтобы было проще создать новую компанию, чем ругаться с совладельцами.
Это уже полная жесть. Вы сначала берете деньги инвесторов, а потом если они вам перестали нравиться, основываете новую компанию и забираете 80% сотрудников и клиентов? Да вы обычный мошенник-аферист. И вы еще с гордостью об этом пишете? И вы меня упрекаете в том, что я якобы хочу положить деньги себе в карман? Рассуждаете о справедливости? Вы просто эталонный лицемер.

Из-за таких робингудов как вы, в вашей стране и нет рынка венчурных инвестиций.
Остапа понесло…

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

А коллектив единомышленников и должен уходить вслед за лидером. На то они и единомышленники.

Историй таких много на хабре. И про ссоры соучредителей и про инвесторов. Когда один трудится, а другой стрижет купоны — всегда есть конфликт интересов. И даже на бесплатных проектах форки нередки. Тот же bitcoin или LibreOffice.

Может быть вы просто злитесь, что за вами люди не пойдут?
ни имея ни одной акции я разрушил весь российский рынок
Не льстите себе. Я ведь не сказал что лично вы. Жулики вроде вас, которые «кидают» инвесторов, создают атмосферу болота, в которое лучше не соваться. Может потому вы акциями и не владели, что жуликам их не особо стремятся раздавать?

А коллектив единомышленников и должен уходить вслед за лидером. На то они и единомышленники.
Вы ведь упомянули, что ваш гендир заберет 80% клиентов. Они тоже ваши единомышленники? Дайте угадаю, мотивацией увода клиентов опять послужит ваша личная и эмоциональная «справедливость»?

Когда один трудится, а другой стрижет купоны — всегда есть конфликт интересов
И именно поэтому создается сущность именуемая компанией, где права и обязанности каждой из сторон регламентируются и защищаются. А вы, как любитель нарушать правила и не следовать своим словам, с гордостью описываете как вы готовы «кинуть» часть учередителей. Российский бизнес, бессмысленный и беспощадный. Я понимаю, у вас свои реалии, но может не стоит хотя бы гордиться тем, что вы жулик?
Жулики вроде вас, которые «кидают» инвесторов

У меня к вам странный вопрос — вы не хотите научиться читать то, что написано? Не первый раз вас ловлю на том, что написано одно, а прочитано вами совсем другое. Написано было "владельцев", а читаете «инвесторов».

Дайте угадаю, мотивацией увода клиентов опять послужит ваша личная и эмоциональная «справедливость»?

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

Я понимаю, у вас свои реалии, но может не стоит хотя бы гордиться тем, что вы жулик?

Каждый судит по себе.

А вы, как любитель нарушать правила и не следовать своим словам, с гордостью описываете как вы готовы «кинуть» часть учередителей.

Замечательно. Очень советую всем, кто у вас работает — прочитать ваши комментарии. Просто для понимания вашей сути.
Уволиться — это право любого работника. Почитайте законы. А вам хочется командовать рабами с пожизненным наймом.

Не хотите перехода — включайте в трудовой договор запрет на работу в компании аналогичного профиля после увольнения. Ну если ваш КЗоТ такое ограничение рынка труда позволяет.

Скажите, а вы когда свою компанию открывали, случайно не удрали с know-how, полученным у своих бывших работодателей? Что-то ваше упоминание жуликов намекает на это.
Написано было «владельцев», а читаете «инвесторов».
Вы, как типичный жулик, путаетесь в показаниях. Читаю именно то, что вы написали, специально для вас подсветил:
Тогда не используйте инвесторов и не раздавайте опционы. Как только у компании несколько владельцев — возможна ссора между ними и раздел компании или переход управления в другие руки. 20-30% в чужих руках — достаточно для того, чтобы было проще создать новую компанию, чем ругаться с совладельцами.


Очень советую всем, кто у вас работает — прочитать ваши комментарии. Просто для понимания вашей сути.
Боюсь представить, что будет если соучередители вашей компании прочитают ваши комментарии. Где вы описываете что ваш гендир с легкостью готов их кинуть и основать новую компанию, уведя 80% сотрудников и клиентов. Вы, похоже, крупно подставляете своего гендира просто потому что в интернете кто-то неправ. В очередной раз вы показали, что личная эмоциональная «справедливость» для вас важнее интересов компании.

Скажите, а вы когда свою компанию открывали, случайно не удрали с know-how, полученным у своих бывших работодателей
Нет, это ведь ваша схема. Я работал в совершенно другой области. Мое ноухау придумано и разработано лично мной, на основании собственного опыта.
Боюсь представить, что будет если соучередители вашей компании прочитают ваши комментарии

Правильно боитесь, ибо дурного ничего не будет. Гендир и владелец компании у нас в одном лице.

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

Мое ноухау придумано и разработано лично мной, на основании собственного опыта.

А вы представьте, что будет, если вас выкинут из компании? Утретесь и решите, что это на благо? Или пойдете строчить по всем формам гневные письма?

Вы так уверены в себе, что даже написать, чем вы занимаетесь вам страшно. Одни общие слова.
Вы лучше подумайте, что будет, если Илон Маск уйдет из Теслы?
К сожалению Илон Маск в мире один, а компаний — миллионы. Им как-то нужно функционировать без Илонов и Стивов.

А на каждого Джобса, возродившего Эпл, найдется тысяча Джонов Доу, угробивших свои компании.

А вы представьте, что будет, если вас выкинут из компании?
Волков бояться — в лес не ходить. А представьте что будет если вас машина собьет? Требую срочно запретить автомобили и дороги!

Кстати, что ж вы так внезапно Джобса и Маска полюбили? Они ведь, злодеи такие, выдавали работникам ненавистные вам опционы.
К сожалению Илон Маск в мире один, а компаний — миллионы.

В малом бизнесе много компаний, где владелец, гендиректор и главный инженер — это один и тот же человек.

Это такой стартап-переросток с возрастом 5-10-20 лет. Больше некоторого размера ему укрупняться не выгодно по многим причинам. Ну хотя бы потому, что хочется заниматься узкой областью.

Теперь понятно, почему такая компания умирает с уходом создателя? Ну или возрождается на новом месте с тем же создателем.

Они ведь, злодеи такие, выдавали работникам ненавистные вам опционы

Знаете, опцион apple совсем не равен опциону вашей компании. Ну хотя бы тем, что акции apple ликвидны, а акции вашей компании интересны лишь рейдерам.

Ваш опцион — всего лишь средство уговорить работника отдать часть зарплаты вам.

Вот будете котироваться на NASDAQ по 150 долларов за акцию номиналом в тысячную цента — вот тогда ваши опционы будут наградой.
Знаете, опцион apple совсем не равен опциону вашей компании.
Боже, какой же вы наивный. Впрочем, пример с Apple довольно показателен:

Джобс действительно не хотел давать сотрудникам опционы, наверное потому что он был очень добродушным, и не хотел их обманывать. Даже когда они их просили, душка Джобс осознавал, что опцион — это западня, и жалел сотрудников. Но в компании Apple еще был известный проходимец Стив Возняк, который только и мечтал делать гадости своим сотрудникам. И когда Джобс отказался давать людям опционы, он, этакий негодяй, отдал им часть своих акций! Представляете, какой хитрец?

А еще есть любимая вами Tesla предлагавшая сотрудникам опционы за 6 лет до выхода на IPO. Вот так Илон Маск 6 лет был мошенником и обманывал своих сотрудников.

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

Вы до сих пор не поняли, что со своим совковым мышлением вы живете в перевернутом мире?
И все же, на каждый Google приходится сотня не взлетевших стартапов, где опционы в итоге сгорели, так что те, кто в надежде на опцион отказались от более высокой зарплаты, потеряли.
В сети есть руководства по оценке job offer, там рекомендуют оценивать стоимость опционов и долей в любой приватной компании как 0.
Оценивать стоит не совсем как 0, а как неликвидный актив. Он имеет какую-то ценность, но прямо сейчас его невозможно конвертировать в деньги. Ценность хоть и субъективная, но нужно понимать, кто-то другой (инвестор) уже оценил этот актив в определенную сумму. Поверьте, стоит поторговаться в том числе и за опционы при собеседовании, хотя бы для того, чтоб через 5 лет локти не кусать.

Более того, раз у компании есть инвесторы, получается что какие-то дядьки рискуют своими деньгами в расчете получить какой-то ROI, а вам компания дает возможность получить тот же самый ROi (за исключением preferred stock и множителей, что редкость), не рискуя личными средствами.

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

Если же инвестор в компанию верит, а сотрудник нет, то возникает вопрос: а нафига компании такой сотрудник? Который тупо работает 9-to-5 ради зарплаты. Который, как Jef239, будет наивно думать, что за успех продукта ему полагается премия, но за провал ответственность должен нести кто-то другой. Таких людей обычно нанимают позже, на рядовые должности. Отношение к ним соответствующее, и опционов им в жизни не видать. Можно изредка подкормить премией, чтоб к конкуренту не сбежал.
Нормально оценить стоимость неликвидного актива рядовому сотруднику стартапа ой как непросто. А еще он может за всю жизнь вложиться своим временем ну максимум в десяток таких стартапов, так что он изначально гораздо более чувствителен к риску, чем портфельный инвестор.

Так что, на мой взгляд, 0 — не самая неточная оценка.
Судя по постам TimTowdy точная оценка будет отрицательной. При превращении опциона в акцию ведь платить надо. А с таким отношениям к людям — вряд ли его компания протянет долго.

Учите русский язык, пожалуйста. Вы путаете ответственность с риском. Да, я не готов рисковать своей квартирой ради компании. При этом лет 20 я за ошибки в программе отвечаю своей свободой. Если из-за моей ошибки погибнут люди — меня будут судить. Не инвестора, не директора, а лично меня.

А вот вы — раскрылись. Вы хотите:

  • Рабства. Найма без права на увольнения.
  • Спихнуть свои риски на других.
  • Добровольно-принудительной покупки сотрудниками акций компании.


Можно изредка подкормить премией, чтоб к конкуренту не сбежал.

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

Который, как Jef239, будет наивно думать, что за успех продукта ему полагается премия, но за провал ответственность должен нести кто-то другой

Не пора ли подрасти и начать отвечать за свои слова? Где я писал, что «за провал ответственность должен нести кто-то другой»?
Да, я не готов рисковать своей квартирой ради компании.
Прекрасное сравнение, ведь именно это делают все владельцы опционов.

Вы хотите:
  • Рабства. Найма без права на увольнения.
  • Спихнуть свои риски на других.
  • Добровольно-принудительной покупки сотрудниками акций компании.
Главное объявить оппонента злодеем, доказывать это не обязательно. У вас в голове полный совок и образ злобных буржуев-капиталистов. Давайте закончим этот разговор, я в очередной раз убедился что вы абсолютно некомпетентны и продолжаете жить в Советском Союзе. Крепкого вам здоровья.
Зачем мне доказывать? Все уже доказали вы своими постами.

А живу я не в СССР, а ещё хуже — в мире понедельника. Когда коллега за личный счет покупает оборудование для работы, а отдать счета для оплаты просто не хочет. Когда в отпуск выгоняют, ибо за годы его столько накопилось. Когда люди работаю в выходные, потому что им интересно так жить. Когда гендиректор в 6 утра едет спать, чтобы в 10 быть опять на работе. Когда конкуренты имеют в сотни раз больше народу, а мы делаем то же самое в 20 раз дешевле.

Наша мечта — не миллиарды, а повторить судьбу унитаза. Была такая испанская фирма unitas, название которой стало общеупотребительным названием прибора. У нас есть шанс добиться того же.

Нам так жить интереснее. Деньги — это не самое главное. Намного важнее сказать «а вот это сделал я».

Зато — лизоблюдов у нас нет. И чужой карман мы не смотрим.
При этом лет 20 я за ошибки в программе отвечаю своей свободой. Если из-за моей ошибки погибнут люди — меня будут судить. Не инвестора, не директора, а лично меня.

Ну не преувеличивайте. Если вы не директор, а разработчик (или даже руководитель разработчиков), и из-за ошибки в вашем софте погибнут люди, то лично вас судить могут лишь в одном-единственном случае — если следствие покажет, что вы эту ошибку внесли намеренно, или по крайней мере, знали о ней, о её последствиях, но утаили информацию.
Вы не правы. Ну вот тут, например: Субъективная сторона преступления характеризуется неосторожной формой вины.

УК 26 про неосторожность
УК РФ, Статья 26. Преступление, совершенное по неосторожности

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

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

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


Так что возможен вариант небрежности — «не предвидел, но обязан был предвидеть».

Тут влияет ещё то, что написано в ТЗ и договорах.

Ну как пример — перевод исполнительного механизма в безопасное состояние при отключении контроллера. Если это есть в ТЗ и забыли сделать, а потом погибли люди — это тянет на состав преступления по УК.

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

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

Так что соответствующий кусок кода вычитывало 5 человек с проставлением своих подписей.
Зачем вы даете эту ссылку? Она ведь опровергает ваши собственные утверждения.

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

Я вас больше удивлю, даже люди которые в прямом смысле решают «let them burn» не несут уголовной ответственности. Почитайте про классический пример конфликта этики и закона: Ford Pinto cost-benefit analysis.
Вы настолько великодержавны, что считаете, что Россия должна судить граждан США за смерти граждан США?

В статье приведена куча примеров ошибок, которые проводили или могли привести к смерти/ранениям

Опять соврамши. Где там хоть один пример смерти? ну или хотя бы тяжкий вред здоровью? А что «могли» — законами РФ не карается. Продажа соли в магазине тоже может привести к смерти. Вдруг кто-то слопает сразу килограмм?

Почитайте про классический пример конфликта этики и закона: Ford Pinto cost-benefit analysis.

Почитал. При смерти в любом столкновении виноват… догадываетесь кто? Тот, кто столкнулся. А разработчики виноваты в несоблюдении правил безопасности, то есть ГОСТов, СНИПов, СанПИН и так далее. Так вот, судя по вики, их американские нормы того времени они не нарушили.

Ну в общем в законах РФ вы не разбираетесь от слова «совсем».
Опять соврамши. Где там хоть один пример смерти?
И вы меня упрекаете в незнании русского языка? Сами-то читать умеете? «приводили или могли привести»

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

А разработчики виноваты в несоблюдении правил безопасности, то есть ГОСТов, СНИПов, СанПИН и так далее
Господи, опять техника безопасности строителей. Ну да, прораба могут наказать, если строитель с крыши свалился. Причем здесь software development? Вы точно не путаете девелоперов которые дома строят, и тех которые developers developers developers developers?
И вы меня упрекаете в незнании русского языка? Сами-то читать умеете? «приводили или могли привести»

Угу. Так где пруф, что приводили? А может привести к смерти простое поедание соли. Или сухого молока. Можно насмерть разбиться в ванне. УК РФ не учитывает то, что могло быть. Речь лишь о том, что было.

Поскольку вы плохо знаете русский язык, придется повторить вам то, что я сказал:
Ну как любимый пример — известный баг в круиз-контроле, когда при отказе датчика машина разгоняется до 200 км/ч. Если в ТЗ или нормативке написано, что так не должно быть — за такой баг можно судить (если люди погибли).

Если погибли люди, еслиэто произошло в РФ, если в нормативке написано, что тормоз должен отрабатывать всегда, если разработчик гражданин РФ — то по российскому закону он несет ответственность.

Перечитайте ещё раз условия. Русский язык — он сложный. :-)

Причем здесь software development?

Да у нас все время ГОСТы, а иногда и остальная нормативка. И СНИП и СанПИН бывает.

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

Ну жизнь такая. С одной стороны — GPS, высокоточка, куча хитрой математики в коде, а с другой — СНИПы.
Слушайте, великолепный у вас вышел диалог.
— Разработчик несет ответственность если юзер погиб из-за бага
— Это неправда
— Правда, вот вам пример бага с круиз контролем. Если бы из-за него кто-то погиб, то разработчик понес бы ответственность
— ?!

Вы извините, я-то подумал что вы ссылку ради пруфа привесли. А оказалось, что в качестве пруфа тупо повторили свое утверждение, а ссылка там просто для пафоса. Браво! Чушь, повторенная дважды, звучит в два раза убедительнее. А программист в два раза сильнее, если он в два раза громче стучит по клавишам.

если в нормативке написано, что тормоз должен отрабатывать всегда
Вы опять фантазируете. Ну да, если в законе написано что рыжие вне закона, то рыжие будут нести ответственность за цвет волос. Но там это не написано. «А вот если написать...» — это не аргумент.

Ну или жду от вас государственного норматива применимого к инженерной разработке с такой нелепой формулировкой «Х должно работать всегда».

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

Забавно, вам ведь не известен ни один случай, когда разработчик понес уголовную ответственность за неумышленный баг, и вы даже нагуглить такой пример не смогли. Но вы с упорством продолжаете доказывать, что это так. Потому что вам хочется этой жалкой напыщенности: смотрите какая важная и ответственная у меня работа! Вроде уже в возрасте, а до сих пор комплексуете.
Ну или жду от вас государственного норматива применимого к инженерной разработке с такой нелепой формулировкой «Х должно работать всегда».

ГОСТ Р 51709-2001 «Автотранспортные средства. Требования безопасности к техническому состоянию и методы проверки»

Дальше очень длинно
3 Определения
3.3 время срабатывания тормозной системы
4 Требования к техническому состоянию АТС
4.1 Требования к тормозному управлению
Таблица 1б — «Использование показателей эффективности торможения и устойчивости АТС при торможении при проверках в дорожных условиях»
Таблица 3 — «Нормативы эффективности торможения АТС при помощи рабочей тормозной системы в дорожных условиях с регистрацией параметров торможения»
В таблице 3 нормируется время срабатывания тормозов. Максимум — 1 секунда для ТС, выпущенных до 1981ого года.


Далее идет постановление правительства в котором есть ПЕРЕЧЕНЬ НЕИСПРАВНОСТЕЙ И УСЛОВИЙ, ПРИ КОТОРЫХ ЗАПРЕЩАЕТСЯ ЭКСПЛУАТАЦИЯ ТРАНСПОРТНЫХ СРЕДСТВ
А в нем уже: Эффективность рабочей тормозной системы транспортных средств может быть оценена и по другим показателям в соответствии с ГОСТом Р 51709-2001.

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

Что касается формулировки… Вы плохо понимаете и обычный русский язык, что тут говорить о кацелярите… Упростил я ГОСТ для вашего понимания. Не «всегда», а «за указанное в ГОСТ Р 51709-2001 время».

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

Сотни тысяч людей посадили за саботаж и диверсии в сталинские времена. Десятки тысяч — расстреляли. И не только за ошибки, но и за несчастные случаи. Программистов среди них не было, а вот автоматчики были. Сейчас мы пишем релейные схемы на ladder, а исполняет их контроллер. А тогда были релейные схемы. Но методы их программирования — они с 30ых годов все те же. Так что коллеги.

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

Давайте не будем спорить о вкусе устриц с теми, кто их ел? Вы живете в другой стране. И не понимаете наших реалий.

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

Кстати, следствию ничего не стоит написать, что «умышленно, с целью получения опциона премии» не провел отладку и оставил баг. Как у нас говорят — «это Россия, детка».
Так что пока — допустимо.
Что и требовалось доказать. Вы так пафосно рассказываете, что у вас нереально ответственная работа и вас даже могут посадить за баг! А потом тихо-тихо добавляете: «ну, если вдруг законы перепишут». С такой логикой, рыжих могут за цвет волос посадить, как им наверное страшно жить…

Сотни тысяч людей посадили за саботаж и диверсии в сталинские времена. Десятки тысяч — расстреляли.
ОБОЖЕМОЙ, программистов могут начать расстреливать, если к власти придет очередной Сталин. Какой нелепый аргумент для повышения собственной значимости. Расстреливать могут в принципе кого угодно, сопартийцев, кулаков-буржуев, и даже тех, кто слишком хорошо расстреливал.

Вы живете в другой стране. И не понимаете наших реалий.
Вы, как оказалось тоже. До сих пор бредите Советским Союзом.

Кстати, следствию ничего не стоит написать, что «умышленно, с целью получения опциона премии» не провел отладку и оставил баг. Как у нас говорят — «это Россия, детка».
Ну то есть работа программиста в России очень трудна, т.к. законы не работают. Ваш любимый человеческий фактор и отход от правил.

Вот только непонятно, почему вы программистов так выделяете? Для них жизнь в России как-то особенно трудна? Т.е. программиста могут посадить ни за что (хотя примеров нет), а таксиста или бухгалтера — не могут (хотя примеры есть)? Может пафос-то стоит поубавить?
Вы не правы. Ну вот тут, например: Субъективная сторона преступления характеризуется неосторожной формой вины.

В данном случае я прав, а вы не правы. Инженерная ошибка не является преступлением, и статья 26 к ней не применима.
Тут влияет ещё то, что написано в ТЗ и договорах.

Не влияет.
Ну как пример — перевод исполнительного механизма в безопасное состояние при отключении контроллера. Если это есть в ТЗ и забыли сделать, а потом погибли люди — это тянет на состав преступления по УК.

Верно. Но уголовная ответственность лежит не на разработчике, независимо от условий договора. Уголовная ответственность лежит на руководителе предприятия и на лицах, которые отвечают за безопасность труда. По законодательству виноват не тот, кто сделал бракованный инструмент, а тот, кто утвердил его ввод в эксплуатацию. И это выше, чем любые договорные отношения.
Если разработчик сделал не по ТЗ, значит, заказчику надо было проверять, что проект не соответстует ТЗ. Если в ТЗ не прописали, тем более виноват заказчик.
Ну как любимый пример — известный баг в круиз-контроле, когда при отказе датчика машина разгоняется до 200 км/ч.

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

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

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

Там, кстати, тоже никого за решетку не посадили.

Можно пруф? В любом случае, судить граждан США за происшествия с гражданами США на территории США по российским законам — это какой-то сюр. :-) А в самом США — другая правовая семья. Я вот даже по украинскому праву не берусь консультировать. Схожего очень много, но есть масса интересных отличий, начиная с заключения брака через суд.
Ну я как ведущий инженер проекта такие документы подписывал (со стороны разработчика). А у вас что, тим лид подписи на ввод в эксплуатацию не ставит?

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

ст. 143 УК РФ и постановление Верховного суда «О судебной практике по делам о нарушениях правил охраны труда»
Там четко указан перечень лиц, которые несут уголовную ответственность, если кого-то чем-то убило на работе.
четко указан перечень лиц, которые несут уголовную ответственность, если кого-то чем-то убило на работе.

Только я-то не про ТБ и УК 143 говорю. Вот вам цитата из этого ППВС:

В отличие от ст. 143 УК РФ ответственность по ст.ст. 216 и 217 УК РФ могут нести как лица, на которых возложена обязанность по выполнению правил и норм охраны труда, так и другие работники, постоянная или временная деятельность которых связана с данным производством.

Вы же не принимаете в эксплуатацию продукт на другом предприятии. Вы его им передаёте своей подписью. Это совсем не одно и то же.

Вы при купле-продаже подписываете отдельный акт купли и отдельный акт продажи? Или единый акт приемо-передачи?

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

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

Это замечательно, но скажите, где во фразе «А причем здесь ваша подпись? Вы же не принимаете в эксплуатацию продукт на другом предприятии. Вы его им передаёте своей подписью.» я говорил, что у вас должны быть разные акты? Здесь написано, что ваша подпись не означает, что вы отвечаете за приём в эксплуатацию. По-моему, вполне очевидно, и никаких «чтений между строк» и двузначных толкований тут нет.

Я не слышал, чтобы кого-то из разработчиков осудили, но что прокуратура нервы треплет -это факт. Ну как бы коллеги тоже не дураки и диких ляпов не допускают.

Естественно, если ваша программа кого-то убъет, следствие (а не прокуратура) будет активно с вами работать. Как со свидетелями, если в результате следствия не выявится, что смерть возникла из-за чьих-то намеренных действий. Это не называется «судить». Это следственные действия. Судят, когда уже есть конкретное обвинение и дело передано в суд.
Так что вы отвечаете не за жизни, а за качество. За жизни отвечает руководство вашего клиента.
За чьи жизни? Если вы о ТБ — вы правы. Но я не про ТБ и УК 143 говорю. Падает крыша, погибают люди. Раследование идет по трем направления — виноваты строители, виноваты проектанты, баг в теории. Выясняется, что ошибка у проектантов. Проектанты доказывают, что считали по программе. Выясняется, что в программе не реализован кусок расчета из СНИП. Зевнул разработчик, бывает.

Кого виновник? Тот, кто поставил подпись, что программа реализует весь СНИП. То есть тимлид разработчиков.

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

Можно много таких пафосных историй высосать из пальца, но зачем? Чтобы создать иллюзию собственной важности?

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

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

Нет. И в данном случае обвинят лишь тех, кто проектировал (я имею в виду не инженера, а руководство проектной организации) и принимал в эксплуатацию здание. То, что проектировщик использовал программу с ошибками, это его проблема. Должен был проверить и использовать сертифицированный инструмент. Если же программа ещё и прошла сертификацию, несмотря на ошибки, то ситуация вообще патовая и в российской судебной практике такое скорее всего тихонько замнут.
Да, проектировщик может судиться с компанией-разработчиком в хозяйственном суде, может даже отсудить у неё какие-то средства на компенсацию материального ущерба. Но ни у какого тимлида, что бы он там не подписывал, уголовной ответственности за подобные ошибки не будет.
Обоснуйте. Вы считаете УК 238 не относится к программистам?

Что-то я начал сомневаться, может быть будет два уголовных дела — второе по 238, я в квалификации не силен.

Сертификацию проходят, когда она требуется по закону или подзаконным актам. Если не требуется — то идут гарантии создателей программы.

Пожалуй я попрошу помощи у автора одного из учебников по уголовному праву — два уголовных дела будет или одно.
238-я как раз и применяется к контрафакту и к продаже/изготовлению несертифицированных продуктов в тех сферах, где требуется обязательная сертификация либо производственные нормы. Эта статья не про ошибки в коде, которые повлекли травмы на производстве. Она может быть применима к строительству зданий (т.к. эта область зарегулирована СНиПами), но не может быть применима к разработке конструкторского софта, т.к. в этой области нет государственных нормативных документов, требующих соблюдения каких-то стандартов от программистов.
Что значит «Нет нормативов»? Ну как пример СНиП 52-01-2003. Посмотрите сколько в нем методик расчета для одной балки. А если у нас цех из тысячи балок? Такие вещи уже 30 лет никто вручную не считает. Считают по программам, в которых указано, что они реализуют такие-то СНиПы.

Как они сертифицируются — не знаю. 30 лет назад было неинтересно, да и с тех пор поменялось. ФЗ-184 "О техническом регулировании" упоминает связанным с требованиями к продукции процессам проектирования .

СП 52-103-2007 «ЖЕЛЕЗОБЕТОННЫЕ МОНОЛИТНЫЕ
КОНСТРУКЦИИ ЗДАНИЙ» прямо говорит:

6.3.7 Расчет конструктивных систем методом конечных элементов следует производить с использованием специальных сертифицированных в России компьютерных программ, согласованных с НИИЖБ: Лира, Мономах, STARK-ES и других.

А дальше — самый главный момент. Вы в каком аспекте рассуждаете? В строго юридическом или практическом? Практически мало того, что на два юриста три мнения, в уголовных делах бывает такая чушь, что читать смешно. Но чтобы дело пересмотрелось — надо доходить до ВС РФ.

Как пример чуши. То обстоятельство, что выемка произведена 01.02.2012г., а при осмотре изъятого USB-устройства в суде установлено, что единственный файл создан 06.02.2012г. не ставит под сомнение достоверность содержания данного доказательства. Это, вообще-то даже кассация. Липецкий областной суд. А что творится в районах…

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

У автора учебника я спросил. Будет одно уголовное дело, причем скорее всего по 238. Дальше нужно изучать нормативку и должностные инструкции, но вполне возможно, что отвечать будет программист. Для меня лично — его мнение весомей вашего. Ну как минимум потому, что он кандидат юрнаук и преподаватель ВУЗа. А вы, как я понимаю, примерно такой же дилетант, как и я. Если хотите — перешлю мнение в личку.
Ну вот вам про реальности российского правосудия. "в приговоре вообще осталась одна вредоносная программа WinXPCorpValidCDkey.pdf" Вы можете представить себе, чтобы pdf со списком ключей к винде, назвали вредоносной программой? А российский суд — смог.

Чувствуете насколько практические шансы стать на осуждение больше теоретических?

А вот вам дело Жукова, когда вредоносной была объявлена бухгалтерская программа, которая отказалась работать после срока, на который её купили? Логика у следствия простая. Предприятие купило у программиста программу. Пару лет оплачивало лицензию, потом платить не стала. Программа перестала работать, предприятию принесен вред. Следователь решил, что раз вред — то программа вредоносная. И состряпал дело.

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

Вы по-прежнему уверены, что за баги не сажают? Или мы с вами просто пока ещё не нашли соответствующее дело? Или вас интересует строго юридический аспект?
Вы нить разговора не теряете? Я говорю, что вы хотите премий за коммерческий успех продукта, но не хотите ответственности за коммерческий провал.
Внезапно вы заявили, что у вас-то огромная ответственность, вас даже могут посадить за чью-то смерть или нарушение техники безопасности(?!) при проведении строительных(?!) работ. Ну да ладно, забудем о том, что речь шла о коммерческой ответственности, и о программистах, а не строителях.

Теперь оказалась, что вся ваша пафосная «ответственность» вытекает вовсе не из правовых норм и законов, а из того, что в России плохо работают суды. Т.е. сначала вы пытались ссылаться на законы, задумка провалилась, и вы лихо развернули свои аргументы на 180 градусов. Теперь уже вы стали обосновывать свою позицию тем, что законы (на которые вы сами ссылались) в России не работают. Браво! Вы просто эталон дешевого демагога: меняете позицию как варежки, лишь бы поспорить.

Вот только плохие суды — это проблема каждого гражданина РФ, абсолютно любой профессии, а не исключительно вас. «Состряпать дело» могут и на математика, держащего exit-ноду Tor, и на инвалида в коляске, за разбой. Чего ж вы себя таким особенным мните? Чего же вы сначала пытаетесь тыкать законами, а потом сливаетесь: «законы могут поменять», «суд может состряпать дело».

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

Это ведь сто лет назад на хабре обсуждалось, что ж вы ссылку на какой-то левый вордпресс даете? Боитесь что вскроются подробности? А я не боюсь.

Вот, пожалуйста, почитайте обсуждение: geektimes.ru/post/110628

«Дело состряпали» говорите? Поздравляю, вы в очередной раз публично подтвердили, что вы жулик :)

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

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

Не сажают. Кроме идиотских решений судов первой инстанции, есть и более адекватные вышестоящие инстанции, куда можно и нужно подавать кассационные жалобы, если вдруг произошла подобная чушь.
В любом случае, если с вами произошел такой случай, дело-то не в вашей подписи на документах и не в вашей ошибке в коде. Механизм выбора стрелочников в тех или иных делах не слишком коррелирует с уголовной ответственностью.
Ну вы же читали в кассации про USB-флэшку, файл на которой имел дату позже, чем изъятие флэшки? Ну лично Жукову в кассации повезло — ну так на его защиту встали весьма крутые специалисты, включая автора текст этой статьи УК.

Рассчитывать на «повезет» — это как-то странно. Тем более, что я по одной из профессий тестер, а это означает, что если повезет, то лишь влипнуть в редчайшую ситуацию, а не вылезти их неё.

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

  1. Перепутал рычаг, дергаю за него — печь взрывается.
  2. Вместо нажатия на рычаг перепутал кнопку — печь взрывается телемеханически.
  3. То же, но телемеханика работает через контроллер, а не через реле.
  4. Вместо нажатия на кнопку устанавливаю бит «кнопка нажата» из отладчика. Ну бывает, алреса перепутал.
  5. Бит «кнопка нажата» устанавливается из отладочного кода, в котором перепутан явно написанный адрес.
  6. Бит «кнопка нажата» устанавливается из отладочного кода, который отработал неверно.
  7. Бит «кнопка нажата» устанавливается из боевого кода, который отработал неверно.
  8. Бит «кнопка нажата» устанавливается из боевого кода, во время отсутствия за отладчиком, но присутствия на территории завода.
  9. Бит «кнопка нажата» устанавливается из боевого кода, во время отсутствия на территории завода, но нахождения в командировке.
  10. Бит «кнопка нажата» устанавливается из боевого кода, в опытной эксплуатации (договор не закрыт, ПО не передано).
  11. Бит «кнопка нажата» устанавливается из боевого кода, в опытно-промышленной эксплуатации (другой этап договора)
  12. Бит «кнопка нажата» устанавливается из боевого кода, в промышленной эксплуатации.


Ну вот и укажите этап, на котором уголовная ответственность пропадает. Это при том, что я расписывался в том, что «обязан был предвидеть». И не один раз.
Покажите, на каком конкретно этапе прекращается уголовная ответственность?

Уголовная ответственность кого? Если вы имеете в виду человека, который нажал не на тот рычаг, то в общем случае его уголовная ответственность прекращается, не доходя до самого первого пункта.
В частных случаях, если этот же сотрудник является ответственным за безопасность труда на предприятии, он может нести уголовную ответственность.
Это при том, что я расписывался в том, что «обязан был предвидеть». И не один раз.

Вы расписывались в том, что обеспечиваете контроль и выполнение требований по охране труда на предприятиях-ваших клиентов? Нет? Тогда о чем вы спорите? В УК РФ нет статьи, которая наказывает тех, кто подписывался, что обязан был предвидеть, но не получилось.
Вообще, предлагаю дискуссию завершить. Я вам привел нормы законодательства, привел аргументы. Вы возражаете в духе «а может быть нет», «а я же подписывался», «а у нас такая страна, что по-всякому бывает». Ну не хотите верить, не верьте, ради бога. Это же ваше личное дело, знать ваши права и границы вашей ответственности, или не знать. Вам лучше, если будете знать, но раз не хотите, я не должен вас переубеждать.
Если вы имеете в виду человека, который нажал не на тот рычаг, то в общем случае его уголовная ответственность прекращается, не доходя до самого первого пункта.

И почему вас на УК 143 (Нарушение требований охраны труда) все тянет? Вот как раз он не имеет никакого отношения к программистам. Есть куча других статей для данного случая УК 109 (причинение смерти по неосторожности) особенно 109 часть 2, УК 118 (причинение тяжкого вреда здоровью по неосторожности) опять часть 2, УК 168 (уничтожение или повреждение имущества по неосторожности, УК 217 (нарушение правил безопасности на взрывоопасных объектах) — вы сами привели ППВС, что отвечать может любое лицо, подписавшееся под ТБ, УК 238 (выполнение работ или оказание услуг, не отвечающих требованиям безопасности). В конце концов, при упертости следователя — даже УК 205 (террористический акт).

Собственное любое расследование взрыва с особо крупным ущербом и людскими жертвами начнется с гипотезы про теракт. А особо крупный ущерб — это всего 3 часа простоя. :-) При взрыве печи речь пойдет о месяцах.
Вы расписывались в том, что обеспечиваете контроль и выполнение требований по охране труда на предприятиях-ваших клиентов? Нет?

Любой визит в цех означает или роспись под обязательством соблюдать ТБ или хождение под ручку с сопровождающим. Плюс роспись за электробезопасность с установками до киловольта. Без неё — вы не имеете права даже ноут в розетку воткнуть. Послабление только в том, что мне выговор не объявить за хождение без каски. :-)

В УК РФ нет статьи, которая наказывает тех, кто подписывался, что обязан был предвидеть, но не получилось.

Может все-таки вы имели ввиду «не подписывался»?

А у вас что, сотрудники за электробезопасность не расписываются? И сами приборы в розетки втыкают? Вообще-то это чревато. Лучше и в офисе всем расписаться. Потому как бывали у нас разные случаи. И лучше, чтобы работники знали, что втыкать надо одной рукой, а не обоими сразу.Или хотя бы расписались, что знают.

Вообще, предлагаю дискуссию завершить. Я вам привел нормы законодательства, привел аргументы.

Да вот аргумент ваш — как-то ваши слова не подтверждают. Собственно сильный аргумент у вас был всего один — ППВС. Про УК 143 (ТБ) вы, разумеется, правы, но как раз она к программистам не относится.
Вот как раз он не имеет никакого отношения к программистам. Есть куча других статей для данного случая

Это лишь ваше предположение, причем неверное.
УК 109 (причинение смерти по неосторожности)

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

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

Подписываются, естественно. Но вот если кто-то нажмет не ту кнопку, и кого-то убьет током, они все равно не несут уголовной ответственности. Их подпись юридически означает лишь то, что специалист по ТБ выполнил свою работу — провёл с сотрудниками инструктаж. А значит, если кого-то из них убьёт, специалист по ТБ (то самое должностное лицо, которое и несёт уголовною уголовную ответственность), будет иметь доказательства, что он свою работу выполнял ответственно. Повторюсь, ваша подпись имеет, по сути тот же смысл. Но с другой стороны, куда лучше, если специалист боится несуществующей ответственности, чем наоборот, игнорирует существующую ответственность ;)
Но вот если кто-то нажмет не ту кнопку, и кого-то убьет током, они все равно не несут уголовной ответственности.

Ну вот вам пример. Нажали кнопку в программе — ребенка убило в лифте. Ответственные за ТБ даже в соучастники не попали, хотя их косяки есть. А отвечает — тот, кто нажал.

Вообще вас послушать — так и за ДТП нужно судить ответственного за ТБ, а не водителя. А судят водителя, причем по 109 ч2, если дело было не на дороге. И это несмотря на то, что он ехал на погрузчике с неисправными тормозами.

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

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

А вы что, поверили TimTowdy, что он просмотрел архивы всех уголовных судов мира, включая Северную Корею и Зимбабве? Ну пусть хотя бы по Северной Корее доказательства покажет, что он вообще в её архивы лазил.
Как я уже писал, я не ставлю целью вас переспорить :) Я немного удивлён вашей настойчивостью возражать (причем по откровенно пустяковым вопросам), причем тратить на это, очевидно, немало времени. Я ведь представляю себе, сколько времени требуется на поиск судебных дел, которые как-то касаются вашей точки зрения, а вы-то ещё, судя по всему, и показания там читали, и данные следствия. Как-то вы неразумно распоряжаетесь своим временем, коллега. Впрочем, это тоже ваше личное дело.
Мне бы хотелось вас спровоцировать найти уголовное дело, где за ошибку программиста посадили кого-то другого. Ну скажем ответственного за ТБ.

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

А зачем… Работа у нас такая. Представляете сколько бед может натворить комбайн на автовождении? Или система посадки беспилотников, сажающая самолет на голову людям? Это вот проекты на ближайшие годы. Правда мы там только GPS занимаемся, но общее представление иметь хочется.

И не в «цивилизованном мире», а в РФ.

Тут ещё гадость в том, что мы делаем программо-аппаратные комплексы. То есть моя ответственность за код, а у коллеги — за железо.

P.S А цех с печью на водороде реально был. Там мой код работает уже 15 лет 365 на 24.
Забыл написать. За безопасность кода, сидящего в контроллере, я тоже расписывался. То есть код вычитали и расписались. Но… есть отладка связанной с с контролером части на персоналке, есть изменение с персоналки памяти контроллера.

Кроме того, вы же на расписываетесь за ТБ у себя дома? И все равно, если откроете газ на пару часов, будет взрыв и погибнут люди — посадят по УК 109.

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

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

А вот, для примера, европейские законы:

Ответственность (гражданскую, а не криминальную) за баги несет поставщик.

Максимум за что возможна криминальная ответственность — это преступная халатность управляющего, именно то о чем говоритDrPass. И jailtime, заметьте — аж до 3х месяцев.

Ваша вольная дилетантская трактовка УК никому не не интересна. Ответственность прораба за строителя, упавшего с крыши, эквивалента ответственности за баг только в ваших фантазиях.
Что значит «Нет нормативов»? Ну как пример СНиП 52-01-2003.

Я прошу прощения, а СНиПы — это нормы и правила из какой отрасли из разработки ПО, или всё-таки строительной? И на соответствие СНиПам проверяют программы или всё-таки здания и сооружения?
с использованием специальных сертифицированных в России компьютерных программ

Ну да. Ваша программа сертифицирована? Значит, учреждение, ответственное за сертификацию, проверило и подтвердило, что она считает правильно. Ваша программа не сертифицирована? Значит, директор вашего заказчика совершил правонарушение — принял в эксплуатацию несертифицированный продукт. Причем тут тимлид-то?
А дальше — самый главный момент. Вы в каком аспекте рассуждаете? В строго юридическом или практическом?

В обоих. Понятное дело, что если рассматривать судебную практику в РФ, то (я утрирую сейчас) при желании в каком-то случае вам и наркотики подбросят, чтобы сделать вас виновным вместо сына депутата, который там работает начальником. Но я придерживаюсь принципа разумной достаточности, и в подобные крайности не вдаюсь.
Ну так и давали бы сотрудникам опционы Apple, Tesla и Google. А не компании «рога и копыта», сферу деятельности которой вы стесняетесь назвать.

А что вам очень не нравится отмена рабства — это заметно.
Ну так и давали бы сотрудникам опционы Apple, Tesla и Google. А не компании «рога и копыта», сферу деятельности которой вы стесняетесь назвать.
Как же медленно до вас доходит. Apple, Tesla и Google точно также были компанией «Рога и Копыта» до выхода на IPO. Они точно также выдавали сотрудникам абсолютно неликвидные опционы. Определитесь наконец, считаете вы их за это мошенниками/рабовладельцами, или нет.

Во всем цивилизованном мире, исключая постсовок, опцион является великолепным способом привлечения талантливых специалистов. Это, на протяжении многих лет, делает каждый стартап, и Google, и Tesla, и тысячи других, успешных и не очень. И один только самоуверенный динозавр Jef239 считает, что он лучше других знает, как строить компании. Он никогда не владел опционами, но уверенно считает что они — зло. Таких как вы, Эзоп прекрасно описал в басне «лиса и виноград».
Apple, Tesla и Google точно также были компанией «Рога и Копыта» до выхода на IPO

Пруфы, плиз. Годы начала раздачи опционов и оборот компаний на этот момент. У Apple за 3 года до IPO был успешней компьютер aplle-II, гуглом стали повсеместно пользоваться за 5-6 лет до IPO, Tesla вела массовое производство за 2 года до IPO, Да и вообще изначально бредила о миллиардах.

Помнится, вы писали:
в погоне за мнимыми миллиардами современные инженеры отказываются от миллионов

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

Таких как вы, Эзоп прекрасно описал в басне «лиса и виноград».

Поржал. Хотел бы играть в акции — купил бы. Но у меня с банком договор: он не занимается GPS, а я не играю в акции.
Пруфы, плиз
Пул ESO выделяется либо с момента основания компании, либо с момента получения первых инвестиций. Иначе его придется рисовать из воздуха, и ваших инвесторов это очень удивит. Более того, именно инвесторы обычно требуют его выделять. Учите матчасть.

Первые инвестиции Google получил в 1998 году. Вторые, от венчурных капиталистов — в 1999 (25 млн). Т.е. cap table, со включенным в него ESOP, был максимум в 1999 году.

Доступа к чужим cap table у меня нет, но если уж вам хочется пруфов:
At the time, the startup had only 40 employees, and its doodle game was not yet strong. But Brown had just gone through a plethora of life changes and her future was uncertain anyhow… so she took the job, which started at $450 per week.

Brown’s compensation package also included a bunch of Google stock options. Which, at the time, were worth next to nothing.
Т.е. cap table, со включенным в него ESOP, был максимум в 1999 году.

А ещё весной 98ого гуглом стали пользоваться повсеместно. Так что далеко не «Рога и копыта».

Я правильно понимаю, что историю про apple вы выдумали сами?

Мой совет — учитесь приводить ссылки. А то к бедам с русским языком у вас добавляются ещё и беды с неумением ставить ссылки. Даже что такое пруф вы ещё не поняли.
А ещё весной 98ого гуглом стали пользоваться повсеместно.
И это волшебным образом сделало акции гугла ликвидными? Компании, не вышедшие на IPO, могут за один день из 9 млрд превратиться в ноль, был тут недавно такой случай.

Кстати, если весной 98-го гугл уже был таким ликвидным, что же они в 99-м не смогли продать его за жалкие 750к? Жаль что вас тогда не было в гугле, вы ведь уже тогда знали, что гугл — это ого-го! У них опционы, в отличие от остальных — это не обман и не рабство.

Может вы объясните наконец, в какой ситуации их нужно считать обманом и рабством, в какой нет? А то у вас точка зрения постоянно меняется: всегда / до IPO / до начала продаж или повсеместного пользования / все ок если основатель мечтает о миллиардах. Видимо проблема в том, что о существовании опционов вы узнали буквально недавно из моих комментариев и своего нелепого гугления, и сразу возненавидели их, т.к. у вас они ассоциируются со мной :)
Как я уже говорил, руководитель из вас слабенький, т.к. вы руководствуетесь эмоциями.

Я правильно понимаю, что историю про apple вы выдумали сами?
Я, в отличие от вас, не фантазер, просто добавил сарказма в известную историю. У вас опять не вышло загуглить и поиск какую-то чушь выдал, как было с опционами? Держите.

Кстати, помните вы гордо рассказывали, как нашли ошибку своего учителя по физике? Я ведь уже несколько у вас нашел, а реакция — совсем иная. Далеко вам до того учителя, ой далеко…
Может вы объясните наконец, в какой ситуации их нужно считать обманом и рабством, в какой нет?

Вы такой глупый или просто придуриваетесь? Да как с любым товаром. Если вы любите кошек — котенок будет вам подарком. А если ненавидите?

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

То есть опцион вместо премии — меня демотивирует.

С гуглом,apple и tesla себя не сравнивайте — вы уже убедились, что на этапе раздачи опционов уже было видно, что капитализация растет в разы. Из российских примеров — контакт. Через полгода после создания уже стало понятно, что его капитализация растет.

А сколько лет проживет ваша конторка, работающая в области, которую вам стыдно назвать — непонятно. Может 2 года, может 3, вряд ли больше 5. И ваши опционы — это издевательство над работниками. Дать денег — вам жалко, так что вместо денег — даете право работнику вложить собственные деньги в ваш карман.

Такая вот жадность в квадрате.

P.S уже понял, что пруфы вы давать не умеет. Мой совет — учитесь, это полезно.
Если вы любите кошек — котенок будет вам подарком. А если ненавидите?
Вот в очередной раз выяснилось, что ваши аргументы о недостатках опционов носят сугубо эмоциональный характер, без капли объективности. Ну т.е. их даже аргументом нельзя назвать. Просто мнение дилетанта, который даже толком не смог загуглить что такое опцион.

должен потратить деньги, чтобы потом, при большой удаче что-то вернуть.
Вот мы наконец-то и пришли к главному. Вы осознаете, что ваша ценность в успехе компании близка к нулю. Успех, с вашей позиции, — это «большая удача». Одновременно с этим, вы считаете, что за успех компании вам полагается премия.

«Человек создаёт. Паразит спрашивает: А где моя доля?»

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

Знаете, есть такая шутка: когда человек в жизни ничего не добился, он говорит что выбрал семью. Вот и вы, никогда в жизни ничем не владели, и обосновываете это шуточками про семечки и кредиты. В реальности же, вы никогда ничем не владели, потому что вы не представляете ни для одной компании той ценности, которая достойна владения. Вы обычный неудачник, не добившийся в жизни ничего, пафосно рассуждающий о собственной важности, который хамит любому, кто с ним не соглашается. Жалкое зрелище. У Айн Рэнд такие отлично описаны.

вы уже убедились, что на этапе раздачи опционов уже было видно, что капитализация растет в разы
Не убедился. А вы в очередной раз показали себя полным профаном. О какой капитализации вы говорите? Вы опять употребляете термины не понимая их значения? Оценочная капитализация и Гугла и Теслы в момент раздачи опционов была отрицательной, что вполне себе является нормой для стартапа. А рыночной капитализации вообще не было, т.к. на бирже они не торговались.

Покажите мне пруф, что в 98-99 годах «капитализация» Гугла росла в разы. Иначе вы — пустослов.
Ну что ж, вы отлично показали, и почему вокруг вас образуются подхалимы и почему именно ваши премии демотивируют людей.

Что касается «паразитов», то есть разработчиков — избавьтесь от них. Оставьте в компании тех, «от которых успех компании зависит напрямую» (маркетологов и менеджеров), а разработку забангалорьте в Индию или Иран. Можете даже попробовать оплатить её акциями. Вдруг прокатит? :-)

На этом общение с вами закончено.

P.S. Над вашим опровержением теории академика Амбарцумовой я долго ржал.
Что касается «паразитов», то есть разработчиков — избавьтесь от них
Вы так ничего и не поняли. Я более 10 лет был именно разработчиком и примерно в половине случаев получал опционы от разных компаний. Некоторые обернулись в доллары после acquisition, а некоторые я решил не конвертировать и на них я ничего не потерял и не приобрел.

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

А советы по управлению компанией от закомлексованного пустослова с нулевым опытом управления мне не интересны.
«Некоторые» означает «больше 1». Верно? Значит за 10 лет вы работали минимум в 8 компаниях.

  1. Вы «жулик» и увольнялись сами? Вас уволили, ибо вы не приносили компании пользы? Компания, где вы работали, разорилась? Напоминаю, что вы считаете, что любой уволившийся сотрудник, это жулик, который кинул инвесторов.
  2. О какой лояльности компании и о какой ответственности вы можете говорить, если вы даже не все опционы конвертировали в акции? Компания дала вам почетное право оплатить ее акции — а вы ей не заплатили. Это говорит о том, что вы безответственный работник.
  3. Судя по числу мест, где в работали — опционы никак не спасают от увольнения. В отличие от премий.
  4. Очень печально, что вы пишите «я работал там и там» вместо «я сделал то и то». Получаете, что вы не сделали ничего, чем можете гордиться. За 10 лет — ни одного проекта, которым можно было бы похвастаться. Тогда какой вашей значимости для компании может идти речь?

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

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

Ну как пример. Дано: обычные ПТУшники. Отбор — минимальный, брали всех желающий. Хотели идти в ВУЗ 1-2 человека. Итоги: закончили ВУЗы больше половины, пяток программистов. Да, методика придумана не мной. Макаренко, Фрунзенская коммуна, Башмаков, Поздняков. Но как за месяц из человека, который считает, что не умеет ничего, сделать человека, который умеет почти все — я знаю.Точнее — умею это делать.

Так что не надо сказок. Вам просто не повезло с коллективом. А сил изменить коллектив вам не хватило.

То, что у вас на хабре всего одна статья — преступление.

UFO just landed and posted this here
Технически много что бывает. Например срыв сроков мог вызвать настроение «все равно сроки срываем, давайте уж качественно сделаем». И уже это могло вызвать успешность проекта. А могло быть наоборот, сначала упор на качество, а потом срыв сроков.

А могло быть так, что соблюдение сроков привело бы к катастрофическим недоделкам типа «Любой говнокод, но в срок».

Трудно сказать что-то определенное.
UFO just landed and posted this here
UFO just landed and posted this here
А кого вы помните из тех, кто писал в срок?
Почти любого, кто писал, в том числе, для журналов. Стивен Кинг, Айзек Азимов, братья Стругацкие. Конечно, не все и не всегда писалось в срок, но по большей части.
Собственно все сводится к простой дилеме: Что важнее, интересы фирмы или репутация менеджеров?
Мой друг и я купили квартиры в один день. Наняли бригады строителей для ремонта.
У друга полы и стены оказались считай ровными. А у меня кривизна-кривая и строители ошиблись в расчете материалов, правда еще и часть материалов запороли — чтож ремонт закончить надо: пришлось докупить. Но только они еще и на 2 месяца дольше работали! а мне жилье пока надо было снимать, и теща мозг выносила.
Но строители молодцы- отремонтировали мою кривенькую квартиру, правда дороже вышло в разы и дольше в два раза. И вот они просят еще денег за то что полы кривые были сильно сразу. Как думаете платить им или так отпустить?
У друга полы и стены оказались считай ровными. А у меня кривизна-кривая и строители ошиблись в расчете материалов, правда еще и часть материалов запороли — чтож ремонт закончить надо: пришлось докупить. 

Не очень правильное сравнение, нормальные строители сразу могут определить что и как будет. Программисты увы, они могут только предположить, слишком много неизвестно. Тем более выстрелит проект или нет.

Вы неправильно закончили: Они взяли чуть больше денег и чуть дольше делали, зато квартира получилась 250 метров вместо 50. Дать ли им за такой подарок на чай?

ну по описанию задачи:
1. «денег стоило в разы»
2. про то что это качественно другой результат ничего не сказано — значит понимаем что так и остались 50м но с светодиодами и музыкой

Данный пример со строителями я привел с целью показать аналог в другой высокорисковой и мало определенной области. А то у большинства участвующих в беседе есть соблазн однозначно утверждать «дать премию» хотябы из солидарности за коллег по цеху — разработчиков
По сравнению с разработкой продуктов ремонт квартиры — вообще не рисковая и крайне определённая область.

Я бы премировал, списав провал сроков на кривое планирование сроков.
Однако, при выдаче премии указал бы: премия была бы существенно больше. если бы сроки были соблюдены.

Как уже писали выше, при четко озвученных правилах премировать вторую группу недопустимо. Но! Даже если искать «справедливость», на основе данных вводных этого делать нельзя.

Вводная прямо царство лжи и… ну хорошо, не лжи а манипуляции, которая совершенно определенно склоняет к ответу «премировать». Столько моментов осталось за кадром, что принять взвешенное решение практически невозможно. Я просто оставлю перечень:
1. Мы не знаем как качество разработки нового проекта повлияло на финансовую успешность. Даже кривые программы порой бывают коммерчески успешными если решают потребности пользователей.
2. Мы не знаем как разработчики могли повлиять на оценку сроков и бюджета. Если бюджет и сроки спускаются сверху, то это просто «погода». Сегодня дождливо, бюджет 150 тысяч. Завтра солнечно — 3 миллиона.
3. Мы не знаем как шел процесс разработки. Была ли эскалация со стороны разработчиков о прогнозируемом срыве сроков/бюджета.
4. Мы не знаем менялся ли скоп разработки.
5. Мы не знаем был ли у разработки Product Owner и его роль в проекте.
6. Мы не знаем методологию разработки и в чем заключался bottleneck. Это могло быть и коммуникация, и аналитика, и разработка, и тестирование.
7. Как мерили неподдельный энтузиазм? Не получилось ли так что команда решила освоить новый модный фреймворк и развлекала себя за счет работодателя?
8. Как обстоят дела со стоимостью владения продуктом?
+1
Добавлю, что премирование это вообще зло. Хуже только вручение хрустальных салатниц и дипломов.
Потому, что выданная премия демотивирует других сотрудников, особенно, когда они знают, что премия выдана неправомерно (например, мелким оптом пофикшена серия тикетов, по которым мог быть заведён один-единственный тикет).
При премировании команды — та-же фигня на соседние команды распространяется, с учётом потери информации (Мы тут пашем как лошади, кастомер-критикал проблемы решаем, а они там придумали какую-то фигню и премию получили! Низабудимнипростим! )

Другое дело — устроить общую пьянку (ох, простите, тимбилдинг) с указанием на то, что пьянка проводится на деньги «команды А» за «достижения и победы».
выданная премия демотивирует других сотрудников
Вы можете это как-то обосновать? По моему опыту, это не так.

Типичный пример из моего опыта: компания использует ежегодные бонусы в размере 0.5-4 месячных зарплат, которые получают 90+% сотрудников (не получают только те, кто ну совсем хреново работал, ибо будут скоро уволены, и те, кто пришел меньше, чем месяц назад). Способ вычисления суммы (в процентах от зарплаты) прописан в трудовом договоре и зависит от оценки сотрудника коллегами и начальством (вид функционала таков, что проставлением низкой оценки коллеге нельзя увеличить свою премию), успешности департамента (оценка вывешивается на внутреннем ресурсе) и финансовых результатов компании (публичная информация). По моему опыту, никто ни с кем не обсуждает полученную сумму.

Вот, скажем, я получил премию в 100 тысяч, а мой коллега — 200 тысяч. Оба мы знаем лишь свою сумму и то, что другой тоже что-то получил (и то, второе можно лишь косвенно определить — нужно заметить, позвали ли в день распределения премий коллегу для вручения уведомления о премии). А сумму вообще можно узнать, лишь подсмотрев смс от банка или справку вроде 2-НДФЛ.
Кто именно и каким образом демотивируется в данном конкретном примере?

PS: Очевидно, что можно сделать систему премий, которые будут демотивировать вообще всех, но, на мой взгляд, фраза «премирование — это вообще зло» означает, что мотивирующих систем премирования не существует.
PPS: А вот обратных примеров, когда отсутствие премий демотивирует, в моей практике было достаточно. Когда ты годами каждый день видишь, что коллега ничего не делает, а зарплата у вас примерно одинаковая и премий не бывает, вообще никакой инициативности не остается.
Когда ты годами видишь, что коллега ничего не делает — тут два варианта. Или ты не понимаешь, что он делает. Или все вопросы к начальству.
А оценки… Неформальные оценки ведут к склокам в коллективе, формализованные — к нагонке параметра.
В результате всех действий — команды нету, есть куча ярких личностей, которые готовы быстренько куда-нибудь сбежать. В худшем варианте — есть звизда, которое весь проект тащит и куча ярких личностей, и т. д.
А откуда склоки, если твою оценку знаешь только ты и твой менеджер? У меня были ситуации, когда руководитель ставил плохую оценку, но это было совершенно точно за дело, да и план исправления ситуации всегда составлялся.
В общем, ИМХО, премирование — это инструмент. Может быть полезен, может быть вреден, надо уметь пользоваться.

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

Потому что «было решено выдавать премии командам по результатам соблюдения сроков и бюджетов проектов». И сроки, и бюджет были провалены в разы.

Потому что вводная не является эмоционально нейтральной. Фразы «неподдельный энтузиазм» и «рекордная прибыль» задают позитивный контекст и смещают акценты от факта. Отсутствует точка зрения руководства и руководителя проекта. Вообще подача материала характерна для участника второй группы.

Это может звучать несколько обидно, но программисты это всего лишь один из инструментов на пути к успеху. Как и любой инструмент он может быть хороший или плохой. Но в любом случае он не уникальный. Я работал в разных компаниях и в каждой были отличные спецы. Не больше 10-20% от общего состава. Но больше как правило и не надо. То что сделала вторая команда могло быть выполнено другим коллективом. У победы много родителей, это поражение всегда сирота. Лишь в некоторых исключительных случаях когда в организации бардак и на команду разработки ложится и аналитика, и «видение продукта» в соответствии с ожиданиями заказчика можно говорить о прямой связи команды и успеха продукта. Но это как правило приговор организации.

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

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

В задаче написано, за что менеджмент обязался премировать.
Т.е. если сроки и бюджет соблюдены — есть обязанность выплатить премии.
А вот обязанности ни в коем случае ни за что не премировать, если не соблюдены сроки и (или) бюджет в задаче нет. Это ваше собственное дополнение.
Вы заменили импликацию тождеством и у вас вместо "если соблюдены сроки и бюджет то будет премия" получилось "тогда и только тогда, когда соблюдены сроки и бюджет, будет премия".


Потому что вводная не является эмоционально нейтральной. Фразы «неподдельный энтузиазм» и «рекордная прибыль» задают позитивный контекст и смещают акценты от факта.

В русском языке строго эмоционально нейтральных фраз практически не бывает. Попробуйте сами эмоционально нейтрально описать факты рекордной прибыли и неподдельного энтузиазма.


Отсутствует точка зрения руководства и руководителя проекта.

В задаче отсутствуют любые точки зрения вообще. Только факты.


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

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

Если вы будете говорить это командам в процессе работы над проектом, то как по вашему это повлияет на мотивацию сотрудников и итоговый результат?


Для меня этот вопрос решенный, я так делал и получал отличные результаты. На момент начала проекта наша команда имела вводные в виде ТЗ и сроков. Ввиду нехватки аналитиков/архитектора мы были вольны принимать решения и решать проблемы исходя из собственного соображения. Мы решали в июле как решить проблемы сентября. Мы работали со скопом, с приоритетами. В процессе разработки всегда просто море возможностей. Обычный трейдофф — сделать быстро и дешево сейчас или сократить стоимость владения в долгую. Наш результат был 60% бюджета и на 2 недели пролюбленный дедлайн. С мотивацией проблем не было от слова совсем.

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

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

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

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

Мы не получили никакой премии за проект. Более того, сэкономленные деньги были растащены руководством компании на премии себе. С нами даже отказались обсуждать вопрос хантинга (т.к. у одного ведущего на руках был оффер с зарплатой в 2.5-3 раза больше текущей). Все это довольно быстро закончилось увольнением, где меня лично кинули по скромным подсчетам на 80к премии за предыдущие 3 квартала. Если считать по средней то на 100к.
Попробуйте сами эмоционально нейтрально описать факты рекордной прибыли и неподдельного энтузиазма.

Вызов принят!
Прибыль: рекордная.
Энтузиазм: неподдельный.
Вроде близко? :)
Понимаете, я не пытаюсь навязать вам свою точку зрения. Я просто даю обратную связь. Энтузиазм вообще не относится к делу. Если бы команду приковали цепями и на выходе получился бы такой же продукт это бы не умалило и не возвеличило результат. По прибыли сложно говорить безэмоционально, особенно когда действительно есть чем гордиться. Но надо. К примеру — новый проект увеличи доходы компании на 140%. Или — маржинальность нового проекта составила 50% на этапе разработки, на этапе поддержки ожидается цифра в 80-85%. Или — в первый же месяц число продаж превысило вдвое второй по популярности продукт нашей компании.
Понимаете, я не пытаюсь навязать вам свою точку зрения

Мне прежде всего интересно уточнить вашу точку зрения и ее основания (для вас же).


Энтузиазм вообще не относится к делу.

Относится напрямую.
Тема задачи — мотивация, которая при наличии энтузиазма немного предсказуема.


К примеру — новый проект увеличи доходы компании на 140%. Или — маржинальность нового проекта составила 50% на этапе разработки, на этапе поддержки ожидается цифра в 80-85%. Или — в первый же месяц число продаж превысило вдвое второй по популярности продукт нашей компании.

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


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

Рабство как способ мотивации точно никакого отношения к задаче не имеет.

UFO just landed and posted this here
Я безусловно согласен с вами что энтузиазм это средство сокращения издержек на ФОТ. А вот скажите пожалуйста, не встречали ли вы что у человека энтузиазм перегорает и он понимает что прошедшие N месяцев он работал ниже рынка. И потом финишная прямая — оффер, 2 недели отработки? Или энтузиазм сдувается, но зарплата держит а человек забивает болт на свои обязанности? Мне гораздо комфортнее самому работать по принципу «халтуру не делаю» и в окружении таких же людей. Людей, которые знают себе цену. Понимаете, если у человека нет внутренних мотивов решать задачи, если он разделяет «за это плочено, за это неплочено», он ни за какие деньги выше головы не прыгнет.

А по деньгам есть универсальное мерило — рынок. С премиями ситуация доходит до смешного. Руководитель зачастую оперирует доходом как оклад + премия (гляди как много получаешь). А на этапе распределения премии случаются всякие чудеса и остаешься с голым окладом. Особенно это забавно наблюдать когда правила начисления премии меняются прямо перед распределением. Так что наше все — это оклад. Чем получать 50к оклада и 50к премии, лучше получать 120к оклада. Если можете найти работу лучше — получаете оффер идете к руководству обсуждать ситуацию. Или не обсуждая переходите в новое место.

UFO just landed and posted this here
А вот сравнить 50 оклада + 50 премии и, например, 90 оклада уже интереснее.
Т.е. если сроки и бюджет соблюдены — есть обязанность выплатить премии.
А вот обязанности ни в коем случае ни за что не премировать, если не соблюдены сроки и (или) бюджет в задаче нет.
Наличие исключения подразумевает наличие правила.
UFO just landed and posted this here

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

UFO just landed and posted this here
Ох, как же все сложно… Если бы эта команда работала в стартапе, денег ни у кого не просила, выдала результат и сорвала большой куш — честь им и хвала. Здесь же все финансовые риски нёс работодатель. И работодатель организовал рабочий процесс, который, на минуточку, не сводится к работе одной группы программистов. Здесь и аналитика, и сейлы, и тестирование, и управление, и много, много всякого-разного.

Вот представьте ситуацию. У вы загоняете грузовичок на ТО и вам его делают за 3 недели вместо 3 дней. Потом вы везете товар в другой город и делаете 300% прибыли. А с ТО вам говорят — вот видишь как мы клёво тебя обслужили, давай нам премию. Мог ведь и не доехать. А уж с каким задором и огоньком-то работа шла! А то что вы влетели на штрафы за задержку это их не касается. И что заплатили вы втридорога — ну дык ведь работа почасовая. Значит цена справедливая.
UFO just landed and posted this here
Даже в вашем примере. Повезло что партию товара везти нужно было через три с половиной недели, а благодаря автопилоту и расходу бензина я мог ехать днём и ночью не останавливаясь на заправках. Но при большинстве других раскладов — если я прошу грузовик через 3 дня — я хочу получить грузовик через 3 дня. А не звездолёт через 3 года.
UFO just landed and posted this here
Если бы эта команда работала в стартапе, денег ни у кого не просила, выдала результат

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


Здесь же все финансовые риски нёс работодатель. И работодатель организовал рабочий процесс

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


А с ТО вам говорят — вот видишь как мы клёво тебя обслужили, давай нам премию.

В задаче никто премию не просит.

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


Причины:


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

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

Идея вроде и неплохая, но на настройку системы премирования уходят годы. Плюс, у каждой компании своя культура, свои люди. Кого-то премия мотивирует на трату большего времени своей жизни на проект, кому-то лишь создаёт ненужный стресс, который выливается в ухудшение качества продукта. Есть даже мнение, что инженерам (а не продавцам) нужно просто хорошо и стабильно платить, и тогда они будут работать с максимальной эффективностью.
<премия> создаёт ненужный стресс
Это как?
Если человек и так работает на пределе своего времени, неполучение премии рассматривается как плохая работа. Соответственно, получается, что человек или постоянно под прессингом за неполучение премии, либо тратит больше времени на работу, отнимая его у хобби и/или семьи.
Да, наверное, так бывает.
Спасибо за пример.
Я бы в таких условиях не премировал вторую команду за разработку. Но раз продукт оказался таким перспективным, я бы назначил им соответствующие премии за его дальнейшее развитие.
Здесь уже говорили умную мысль про пересмотр методики премирования… и я тоже согласен что именно в данных критериях премирования премию выдавать не стоит… По двум причинам:
1. Это противоречит правилам премирования, а следовательно снизит прозрачность механизма премирования для сотрудников первой группы. Что так же может подорвать доверие сотрудников первой группы к руководству.
2. Демотивация сотрудников первой группы. Но данный пункт скорее производная от первого чем самостоятельный пункт.

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

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

По такой логике — а если продукт провалился и принёс убытки, депремировать всю команду? Даже если они все заранее знали, что он рискованный и имеет лишь 10% шанса «выстрелить» — и в итоге, закономерно, «не выстрелил», хотя и был технически выполнен на отлично и в срок — просто рынок был уже занят. Это ж было не их решение, начинать проект — такие решения принимаются куда выше по цепи.
Так все просто будут идти только в многообещающие проекты, раз уж там премируют даже за срыв сроков и бюджетов. И избегать всего остального.

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

Заметьте, я не говорю, что премировать ни в коем случае нельзя. Для мотивации можно и уборщице премию выписать по случаю продажи миллионной лицензии на продукт (даже плохо работающей). Просто это вряд ли сильно повлияет на продажи следующего миллиона лицензий.
Если команде было известно, что за успешно выполненный проект полагается премия — полагается премировать. И ином случае получите сильнейший демотиватор, я бы после такого начинал тихонько искать другую работу, просто из за отношения. Работать дальше с такой командой менеджмента нет совершенно никакого желания. Если не известно — скрывать, но вероятность что такое можно удержать в секрете мала. Поэтому — премировать в любом случае. Я бы в дополнение поставил под вопрос возможность решать этим людям, кого премировать, а кого нет. Под еще больший вопрос поставил бы такую схему премирования. Короче — команда ваша не долго проработает с таким отношением, помяните мой слово.
Сроки и бюджет — это не самоцель, а инструмент управления для управленцев. Цель — как-раз таки прибыльный продукт (если прибыльный, значит рабочий и любые оверхеды окупились). Соответственно, привязывать мотивационные премии к этим метрикам можно только при равных условиях на разных проектах, и то — условно.

Давать ли? А почему нет, если есть за что? Это ж не соревнование было, где победитель должен был быть один и первой команде могло быть обидно. А чтоб точно не было обидно, надо всем объяснить ситуацию о разнице в проектах и пообещать усовершенствовать критерии премирования.
После того, как второй проект сделали, проводили ретроспективу, могла ли вторая команда сделать его в тот срок, который был запланировал изначально?
UFO just landed and posted this here

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

Что нужно бизнесу? Деньги.
Какие действия демотивируют вторую команду и сорвут получение бОльших денег? К примеру, штрафы.
Какие действия мотивируют вторую команду еще больше или поддержат мотивацию? К примеру, премии.
Чего стоят правила, если они мешают получать компании деньги? Ничего. Тем более что их нарушение будет в + сотрудникам и не демотивирует никакие соседние команды.
Премию второй команде дать.
Второй пункт не говорит, что выполнение в срок и бюджет является исключительным условием получения премии. Просто другие условия могли не озвучить, и в этом нет проблемы.
Хоть в основе решения по премиям и лежали ценности бизнеса «попадание в бюджет» и «попадание в срок», вторая команда смогла показать, что она способна создать другую ценность, формальная формулировка которой в виде правил была бы слишком запутанной и неэффективной для компании.
да

если сорван дедлайн и превышен бюджет, это ошибка планирования или бестолковый менеджмент, а не криворукие программисты
Одно другому не мешает. Бестолковый менеджмент мог нанять криворуких программистов, ошибиться в планировании и не получить свою премию (которая в процентном соотношении может быть гораздо больше оклада). Тогда за что премировать программистов? За то, что они просто сделали свою работу? Почему тогда и менеджмент не премировать, они ведь тоже старались. Но не шмогли, не шмогли.
Премию можно не давать, а использовать иной метод вознаграждения. Например, повышение по службе или увеличение ЗП, выделение бОльших ресурсов на новый проект и т.д.
Я думаю стоит премировать вторую команду, но тут есть варианты
Если вы успешный управленец, то никогда не будете выбирать между этими двумя пунктами.
В среде управленцев этот вброс ввобще бы не сработал, ИМХО.
А здесь за рамками вопроса осталась стратегия того самого менеджемента: он считает своей ценностью собранную команду, написавшую успешный продукт или же только сам продукт. В каждом бизнесе ответ разный, а ошибка в стратегии приводит к разорению (тоже в обоих случаях).
Первым делом при любом премировании или мотивации нужно
а. перестать демотивировать,
б. не демотивировать дальнейшими действиями (попытками премировать или не премировать),
в. мотивировать учтя пункты а и б.
Ну и за что их премировать? «Скажите спасибо, что вообще сделали»? Тут не премировать нужно, а наказывать виновных.

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

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

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

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

Ответ на вопрос, что за компания
Северсталь, как минимум цех ПХЛ. За простой более 3 часов в месяц по вине службы — снимается премия со всей службы участка. Отдельные службы работают на уровне ни минуты простоя в год. Насколько я знаю ещё депремируют за нарушение ТБ.
возможно, это и нужно компании — делать маленькие безрисковые вещи и не закладываться на rnd с вероятностью выстрела 10%
Премирование в рамках названных условий нельзя. Однако при этом премирование с иной формулировкой и оценкой именно нового запуска можно и нужно. Так у сотрудников сохраниться стимул как к развитию нового, так и стремление в соблюдению сроков и бюджета. Вера и усилия ради двух премий лучше чем ради одной.
Возможно дать деньги только тем, кто работали над ним с неподдельным энтузиазмом. Но сделать так, чтобы менеджер команды побегал на счет этой премии, чтобы для него было явно донесено — сам проект косяк, зря подписался под сроки и бюджет.
1) премировать «по результатам соблюдения сроков и бюджетов проектов» нельзя категорически.
2) премировать надо за «продукт дал компании рекордную прибыль»

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

p.s. Задача создана для разжигания войны в комментариях :)
Мы тут все айтишники и любим четкость и объективность? Есть два вполне определенных KPI, под которыми все подписались.
KPI не выполнены, премию не выдавать, тюнить kpi, если они не соответствуют истинной цели компании.

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

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


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

Закон обратной силы не имеет. Менять законы задним числом в угоду одной команде — демотивирует всех остальных. Пусть вторая команда спросит себя: если бы продуктом занимались не они, а кто-то другой, был бы у него тот же самый успех? Вероятнее всего — да. А если успех продукта не зависел от команды напрямую, то и награду за успех они получать не должны.

Если команда работает за зарплату (представим себе обычный бодишоп), то успех/провал продукта вообще напрямую не влияет на премии/зп. Никто же не штрафует команды за провальные продукты, так зачем же награждать за успешные? Как ни прискорбно это признавать, роль условных «программистов» в успехе продукта обычно мала, поэтому и премий за этот успех они не получают.

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

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

Articles