Комментарии 54
Ну и начальство всех компаний — в Москве. А собственники — на Кипре.
И по деньгам решают только они.
Мыслю то так же, а вот жить в этой парадигме чет не получается =)))
Давайте считать, что такой человек — это я? Серьезно, может и не до конца, но стараюсь стремится мыслить такими же категориями. Однако, объективная реальность возвращает меня к сущности рыночных отношений в отдельно взятой стране. И, к сожалению, она звучит так: чтобы корова меньше ела и больше давала молока — ее нужно реже кормить и чаще доить. Я работал в оутсорсе, был наемным рабочим в среднем и крупном бизнесе и не встречал, чтобы не продающим подразделениям выплачивали процента с оптимизаций. Причем, даже в тех случаях, когда эта оптимизация была видна в деньгах сразу и всем. Условно, строили объект за 10n денег, вызываюсь добровольцем с рац. предложением. Применяем мои подходы и строим уже за 8n денег с сохранением сроков и повышением качества. Результат для меня лично — спасибо и включение меня в эту активность на принудительной основе. Когда встал вопрос о повышении з\п был ответ о трудных временах, хотя 1n из экономии с одного объекта — закрыл бы все финансовые вопросы по индексации на год.
Остапа понесло… Причем, следуя своим правилам при отработке моей рацухи я раскрывал суть вносимых изменений, по сути из шаманства отдавал людям методологию. И тут я лишился главного козыря — чуда нет, это можно легко повторить и без меня. Было бы желание. А значит нет смысла меня удерживать. Не нравится з/п? Ну иди поищи где лучше. Нашел, всем доволен, но и на новом месте вижу сохранение подхода к дойке. Единственный раз когда мои усилия сказывались на кошельке здесь и сейчас, это когда я был участником маленькой ИТ артели по обследованию юр. лиц. Там все было просто — 5 человек, по сути и работники и учередители. Сами пашем, сами пляшем.
По крайней мере в реальном мире такое случается.
Нет, конечно. Он же и за эти деньги пользу приносит, зачем ему ещё?
Лучше всего работа измеряется в долларах)
Вы на ревью озвучили набор фактов?:
— я стою компании X $
— я проявил инициативу(то есть сделал больше, чем ожидалось), что принесло годовую прибыл в размере Y * X $
— За это усилие я ожидаю получить премию = 0.05 * Y * X $
ВАЖНО:
1) все вышеперечисленное не должно быть для менеджера неожиданностью. Если для менеджера это «получилось» выглядит как «получилось вдруг» — то ему будет сложно выполнить пункт о премировании. Это тоже работа, которая не за 5 минут делается.
2) Разовое достижение — разовое поощрение.
3) Достижение должно однозначно ассоциироваться с Вашей инициативой. Менеджер должен четко понимать, что речь идет об extra value
следует «ой, блин, это ж сколько он денег принёс, даже сам не понимает»?
С деньгами он готов расстаться еще в тот момент, когда поднял трубку, зашел в офис или отправил электронное письмо.
А вы решили его проблему в 2 раза быстрее обычного и просите у него в 2 раза больше денег. Или наоборот: задержались на день — получили половину зарплаты. Ну ну… Это не так работает. Во всяком случае не для наёмников с ежемесячным окладом.
Но автор может и сам расшифровать ее, полагаю)
иногда разработчики готовы откладывать в долгий ящик задачи, которые могли бы принести профит компании. И чем раньше они будут сделаны, тем больше профита (не факт, что материального) могут принести. И этот профит может быть легко извлечен за короткий срок, но зачем-то задвигается подальше.Честно, никогда не видел ни на одном конкурентном рынке, чтобы кто-то отказывался от профита вот просто так, из вредности и любви к искусству. Разработчики, как правило, умеют считать, и выгоду видеть тоже.
Обычно причина «откладывания» довольно очевидна, и укладывается в комбинацию из следующих пунктов:
1 — профит не такой уж и большой
2 — срок не такой уж и маленький
3 — и профит и сроки — вилами по воде (непредсказуемые риски)
4 — таких профитов уже 3 штуки в работе и ещё 5 в очереди
5 — нематериальные профиты когда-нибудь потом — это конечно хорошо, но ЗП неплохо бы платить каждый месяц
С точки зрения простого разработчика все просто, есть в очереди 10 задач, выбираешь самую приоритетную.Ресурс разработчика ограничент и он не может сделать все 10 сразу.
А менеджер(или заказчик) уже может управлять приоритетом, чтобы самые важные(или денежные) задачи были выполнены первыми.
И тут мы такие «вау, у нас же там деньги сидят на стульчиках!». И что? Увеличить команду, чтобы быстро окучить всех тех клиентов, которые на стульчиках? А потом мы с этой командой что делать будем, платить им зарплату в надежде, что вдруг когда-нибудь у нас скорость поступления денег вырастет? Или говорить «ой, извините, у нас деньги в очереди кончились, идите отсюда»? Во втором случае уже на второй цикл действие «увеличить команду» перестанет работать, никому не захочется идти к нам трудоустраиваться. А в первом ФОТ быстро выест все те деньги, которые мы освоили чуть быстрее, и дальше что?
Т.е. формулировка хорошая, когда бизнес развивается с постоянным ускорением. Но поскольку, вроде бы, из пластикового муравейника нас выпустили, реальный окружающий мир таки хочет от нас баланса, который в том числе означает и очередь клиентов на стульчиках из-за неравномерности поступления задач.
Во-первых, у его клиентов цель — кинуть в кого-нибудь деньгами. В реально мире, цель заказчика — получить как можно больше ништяков за как можно меньшее количество денег. При том, список желаемых ништяков, часто ещё и противоречащий сам себе, приходится клещами вытягивать целый месяц, а смету и дедлайн требует указать сразу.
Во-первых, у него все исполнители только сидят и ждут прихода каждого нового клиента, и всё бросив начинают водить хороводы вокруг его пачки денег. В реальности, в успешных компаниях они, как правило, загружены на месяц-два вперёд освоением пачек денег от предыдущих клиентов, и на «всё бросить и начать облизывать нового потенциального клиента» времени зарезервировано совсем немного. На «быстро глянуть» одного-двух в неделю ещё может и хватит, но точно не на детальный анализ всех и каждого.
Такой подход работает разве что на больших галерных флотах, когда есть отдельный предпроектный отдел, который пол жизни проводит в горячем резерве в режиме ожидания, чтобы при появлении на горизонте клиента максимально быстро подскочить и «чего изволите?». А в очередь ближайшей освободившейся команде гребцов потом отдаётся как раз понятный список задач, номинированный в попугаях.
Советую прочитать про Теорию Ограничения Систем. В каждом случае бутылочные горлошки могут находится в разных местах. Вот побегут программисты быстрее, а все упрется в юристов или бухгалтеров. Начать надо с измерений. А если проблема в скорости программистов, возможно, нужено больше программистов или другой подход к организации работ над задачами. Оставлять программиста один на один с задачей или с клиентом не самый лучший вариант.
Эта сказка про распил бюджета, а в реальности же деньги эти не просто так в систему падают и не просто так ждут, потому что есть риски на эти самые деньги попасть.
Идея не нова и приводит к тому, что разбирают только жирные таски а голые так и весят несделанными
Утопично и вообще фигня
Моё мнение: статья о том, что многие участники бизнес-процессов не задумываются о ценности своих задач и мерилом работы считают даже не усталость, а пустой таск трекер в любом его проявлении. И даже не важно разработчик это, дизайнер, бухгалтер или Людочка — секретарь.
Другой вопрос, что оценить ценность задачи сотрудник может, только обладая довольно большим пластом информации о текущем состоянии дел в организации, т.ч. финансовой. А большинство руководителей не допускают линейных сотрудников к этим данным.
Посему сохраняется статус-кво.
2. Лучшее — враг хорошего
3. Надо уметь оперировать с верхними уровнями воронки продаж, занимая клиента уточнением ТЗ, составлением договоров, и прочими первичными процессами, параллельно планируя разработку на будущие месяцы
4. Если клиент четко знает чего хочет, и нужно вот прям сейчас — добро пожаловать на апворк. Не подходит потому что задача уровня энтерпрайз? Ну, в энтерпрайзе быстро не бывает.
Нет, метод так-то рабочий, но только там, где оплата сдельная. Тогда программист понимает, что вот прям вот в этой пачке лежит несколько купюр, которые лично его. Наглядно так получается, заставляет взбодриться (а если ещё и подержать дадут — так и вовсе).
Проблемы две: первая — при таком подходе вся жизнь программиста происходит «от пачки к пачке» (а это не то же самое, что скучный оклад раз в месяц, это, как было сказано выше, бодрит), что сказывается на нервах не лучшим образом, а программист — существо нежное, ранимое, психика на такие вещи слабенькая совсем.
А вторая проблема — мысль, которая рано или поздно в такой ситуации приходит в голову любому: а зачем брать себе из этой пачки несколько купюр, если можно взять всю пачку?
UPD: А, ну и третья проблема — если клиент достаточно «жирный», и потребность у него постоянная, а задачи ему программист слету решает, то тут уже заказчик смекает: позову-ка я этого толкового парня к себе и платить буду не пачку, а, скажем, треть пачки — это всяко больше тех нескольких купюр, которые сейчас программист за задачу получает, но намного меньше, чем заказчик сейчас отдает.
Отличная статья, спасибо!
Также весьма интересны комментарии. Так уж сложилось, что большая часть аудитории — всё-таки исполнители, не допущенные непосредственно к деньгам клиента. Разумеется у них несколько иной взгляд на положение дел. И нельзя сказать что взгляд неправильный — он правильный с их стороны, и врят ли есть смысл убеждать их в обратном. Просто когда сформировался такой взгляд на деньги/задачи как в статье — исполнитель превращается в предпринимателя и уже не может спокойно работать в найме.
Давайте решим несколько денег