Comments 56
Как мы отдали 70% бизнеса за сайт на вп.
Мир не идеален, а если бы был - в нем можно было бы спланировать сроки. ПО не станок, но и платят не как на станке.
Очень интересное пожелание от наемного работника- получить долю в проекте)))А больше ничего не нужно, точно? Хочешь долю-работай бесплатно, неси риски в соответствии с долей-своим имуществом. Не устраивает-открывай свое дело и неси риски сам.
Можно и так, почему нет? Просто обычно получается что-то между, т.е. ниже зарплата и небольшая, при этом, доля.
Я прямо сейчас так и работаю. Делаю игру для VR-арены на анриале (и заодно изучаю анриал). Получаю столько, чтобы на жизнь хватало. Потом заказчик хочет продавать лицензии на разработанные нами игры другим аренам, и тогда я уже за долю от продаж буду работать. А даже если ничего не выйдет -- получу кучу опыта сразу по большинству направлений в разработке игр (особенно мультиплеер+VR) и игры в портфолио. Хоть сейчас и немного зарабатываю, на дистанции в любом случае буду в плюсе
Посчитай, на дистанции ты будешь в минусе
А это уже как повезёт, 20 лет работаю в гейм деве, с последним заказчиком договорились, что получаю 1к$ чисто на поддержание штанов+500$ доплаты в долг и вычтим их с будущей прибыли, в итоге проект принёс уже значительно больше, чем я рассчитывал.
Ну я мог бы погружаться в геймдев за 0 рублей, а тут погружаюсь + выполняю реальную задачу + еще деньги получаю за это. Да, зарабатываю сильно меньше, чем до этого получал на фулл-тайме в бэкенде, но я все равно рано или поздно ушел бы в геймдев. Просто все не мог заставить себя (программировать вечером после дня программирования -- душило сильно), а тут такой случай удачный.
Ну и когда говорю, что останусь в плюсе -- имею в виду не только деньги или опыт.
Если он возьмет и бросит проект что будете делать? Люди это непредсказуемые субъекты они могут помочь или предать проект - неизвестно. Доля в проекте это очень большая ответственность ты не можешь это росто поручить разработчику с рынка.
Сроки это двигатель проекта. Это особенно заметно если ты сам начинаешь проект. Сроки неограничены полная свобода. Но никакой мотивации! Сроков нет и твоя классная идея пылится. Не потому что она неработоспособна как раз наоборот а потому что просто нет мотивации. Никто не ограничивает сроки и ты откладываешь несоблюдая ответственность перед проектом.
А потом такие вот кабанчики ноют, что никто рвать жопу ради чужого бизнеса не хочет, все обленились, им только зарплату подавай, а работу брать не хотят, вот уроды какие!
Очевидно, что на зарплату по рынку и долю - никакой собственник не согласится. На зарплату ниже рынка и долю - может быть интересно и собственнику и тимлиду.
Дык нормальный бизнесмен никаким своим имуществом не рискует, это удел мелочи. Юрлицо так-то отдельная личность и существует помимо своего владельца даже юридически, соответственно юрлицо рискует только имуществом юрлица)
Ну, двадцать пять лет назад стартапы для привлечения ценных спецов использовали этот приём. Их нанимали на зарплату (нехилую, причём) и подписывали контракт на долю в случае успеха стартапа (успехом считалась либо продажа стартапа с прибылью, либо устойчивая прибыль и выход на рынок акций, после чего контрактер мог продать свою долю, например). Это очень сильно стимулирует...
Насчёт рисков с имуществом - это зависит от формы собственности. Если это какое-нибудь ООО с уставным капиталом в десять тысяч рублей - при чём тут собственность?
Ну можно заложить собственность и купить железо, вот и будет риск собственностью)
Я не спец, конечно, в этих бизнес-делах, но такой ход - это инвестиция в предприятие. Риски инвестора - это его личные риски, почему их кто-то должен разделять? У инвестора своя часть, у участников по контракту - своя... Это к вопросу о
Хочешь долю-работай бесплатно, неси риски в соответствии с долей-своим имуществом
Чтобы получить долю нужно что-то инвестировать (внезапно), тут буквально это и написано) Либо только время, либо время и что-то еще. По большому счету разницы нет, время тоже можно пересчитать в капитал, и рискнуть недвигой может оказаться выгоднее чем например 10 лет работать без зп)
Ну, мой-то комментарий о другом... Я отвечал на подход "хочешь долю - работай без зарплаты и рискуй собственностью". В нулевые выделение доли в стартапе (при наличии зарплаты и отсутствии рисков) было способом привлечь особо ценных кадров...
Вообще, вот эта фраза "рискни недвигой" подразумевает, что деньги от инвестора - это кагбэ кредит, который обязательно надо отдать, да ещё с процентами... Как мне кажется, деньги для инвестора - это расходный материал. Не выстрелило - ну, потерял он эти деньги - это его риски, а не того, кому он эти деньги дал (он же их не просто так дал, а в надежде вернуть сторицей, если,например, стартап "выстрелит"). То есть, если ты берешь кредит, то в случае удачи стартапа кредитор ничего, кроме своих денег и какого-то процента не получит. А вот инвестор является собственником части прибыли в зависимости от инвестиции...
Подход к теме сроков может быть таким:
Причины срыва сроков. Недостаток компетенций у исполнителей, диверсия, изначально нереалистичные сроки.
Источники ошибок в прогнозировании сроков. Как прогнозировать сроки завершения разработки. Какие существуют методы предсказания. Признаки указывающие на низкую скорость процесса разработки.
Можно ли управлять временем разработки. Какие есть механизмы ускорения процесса (усиление мотивации команды, добор/замена специалистов, аутсорс, покупка готовых решений).
Как выявить диверсанта.
Как мотивировать команду. Шантаж и угрозы против поощрений. Оценка эффективности подходов.
Секретные сроки, тимлиды телепаты... Ууу...
Бизнесу нужны оценки и сроки и от этого никуда не деться. Иначе невозможно приоритизировать задачи, планировать работу и распределять ресурсы. Без сроков например не понятно - взять задачу А которая принесёт потенциально 3 профита, или Б которая принесёт 7. Если А делать 1, а Б - 10 станет очевидно, что брать надо А, и даже при промахе оценки в разы это будет верно.
Временные рамки также позволяют разработчику реактивно реагировать на изменение понимания задачи - например осознав на 1/3 срока, что задача не уложится и в х2 - разработчик может пойти к ПО и скорректировать либо сроки либо объем задачи. Часто режут задачи чтобы уменьшить ттм в таких случаях. Если разработчик сроков не знает - реагировать на них он не может.
Ну и в целом - в разработке как будто все и так понимают, что оценки и сроки - это прогноз а не факт
Короче говоря суть в том, что тимлид должен пахать как папа Карло, а чтобы ему было интересно, давайте возьмем его в долю.
Не думаю, что деньги работают в плане настоящей мотивации. Да это приятно, много получать и человек будет искать пути удержаться и дальше получать деньги, но это не может заставить человека по-настоящему увлечься проектом, гореть желанием достичь какой-то цели, сделать что-то лучшее в мире. Ничто не может, это уже на старте должно быть внутри человека, поэтому так важно нанимать правильных людей.
Я работал разрабом в застойном стартапе, где тимлид хотел соскочить потому что как мне показалось спустя много времени потерял интерес. CEO хотел чтобы он остался поэтому ему наверное подняли вознаграждение. Но лучше не стало, тимлид стал служить просто как прокси. CEO требовал сроки у тимлида. Тимлид требовал сроки с разрабов, просил чтобы они сделали декомпозицию на подзадачи и оценили эти задачи. Разрабы по сути были сами себе менеджеры и называли какие-то цифры за которые по их ощущениям это можно сделать. Если тимлиду цифры не нравились, то он говорил: "Ну ты чё, это много, давай меньше, надо быстрее...". Естественно сроки никогда не выдерживались. Ну были еще другие проблемы из-за которых разрабы затруднялись адекватно оценивать сроки. Например, чтобы снизить бас-фактор менеджмент устраивал постоянные ротации чтобы у сотрудников развивать кросс-компетенции. Это работало так же как это работает на утке, она может ходить/плавать/летать, но делает все это хуже чем гепард/акула/орел. Поэтому разрабы теряли глубокое понимание областей системы и не могли уже адекватно оценивать объемы требуемых работ.
А чтотделать, если к срокам привязан? Не из серии - хотелка руководства, а законодательство, или договор заканчивается и нужно на что-то новое переезжать? Или еще что-нибудь (особенно показательно было в ковид, когда все изменения как из рога изобилия сыпались).
Ну то есть когда речь не про новую фичу, которая просто модная (хотя тут тоже гонка с конкурентам), а вот что-то серьёзное?
Я работала на разных проектах. У меня не редко были случаи, когда прилетали изменения, которые чуть ли не вот щавтра на прод надо. Причины разные по сжатым срокам. Начиная от раздолбайства, когда просто забывали заблаговременно уведомить о важных изменениях в законодательстве, заканчивая тем, что нам в срочном порядке нужно было реализовывать функционал, без которого компания просто не могла работать во воемя локдауна и это финансовые потери (причем серьезные - полная остановка продаж).
Или (опять же помятуя ковид) как в срочном порядке разрабатывали различный функционал на госуслугах (не моя команда, просто как пример).
На самом деле, весь исходный пост выглядит как "не довите на меня, как сделаю - так сделаю, чего вы прицепились!!!")
Это классический случай, когда сроки спрашивать не надо с разработчиков. В таких случаях сроки надо ставить. А разработчики должны их выполнять, жертвуя или качеством или овертаймами, за которые должна платить фирма... Ну а потом отпуска-отгулы и т.д. с одной стороны и тех.долг с другой. Отпуска и отгулы, чтобы компенсировать психологический перегруз it команды.
Начало статьи "сроки - это миф". Конец статьи "надо выставлять сроки, но никому не говорить о них". П - последовательность.
Очередная идея работника о том, как бы так делать, чтобы за это не отвечать и получать зарплату.
Какая разница КТО ставит сроки? Какая разница насколько сроки ОБЪЕКТИВНЫ? Какая разница сколько платят тому, кто ставит и контролирует сроки? Т.е. разница в целом есть, но всё это не так важно как сам факт. Сроки, это:
Показатель работы
Инструмент управления людьми
Поэтому ерунда у вас полная, автор.
Вспомогательный или универсальный поддомены — это уже что-то известное, например, очередной интернет-магазин, там всё понятно, и ожидать чего-то нового неразумно. Основной же поддомен приносит бизнесу конкурентное преимущество — именно то, благодаря чему бизнес зарабатывает деньги. Так вот, вспомогательный поддомен — это ваш портрет, портреты художник рисовал, возможно, уже ни одну тысячу раз, а основной поддомен — ваш персонаж.
Ну вы как-то очень уж сильно упростили суть поддоменов из книги.
Основной поддомен(Core subdomain) не обязательно означает, что у вас там что-то супер сложное и неизведанное. Просто это тот сабдомен, который отражает истинную суть вашего бизнеса. Вообще, весь смысл введения этих сабдоменов в тдд заключаетя в том, чтобы при разбиении проекта на части понять, что делать самому, для чего использовать готовые решения, а что можно отдать на аутсорс. Именно так автор и описывает назначения сабдоменов.
Универсальный сабдомен подразумевает части продукта, которые универсальны для всей отрасли, для таких нужно брать готовые решения. Например база данных. Ну не писать же это самим, возьмите один из вариантов.
Вспомогательный сабдомен это что-то, для чего нет универсального готового решения, т.е то, что придется разрабатывать, но при этом, это не является отличительной чертой вашего бизнеса, благодаря чему это можно отдать на аутсорс, например.
А основной сабдомен просто означает те спецефические фичи, которые уникальны для вашего бизнеса, от которых он зависит, именно по этому их нужно делать самим и нельзя никак делегировать, так как это сердце вашей компании.
это не означает, что в рамках Core subdomain не будет абсолютно обычных и предсказуемых задач, что нельзя ставить сроки на разработку задач этого сабдомена и что это невозможно контролировать.
Именно процент от прибыли — вот что по-настоящему замотивирует человека.
С какой стати тимлиды решили, что все держится на них и только они ответственны за бизнес результаты, только они должны получать процент от прибыли? Мог бы упомянуть что все аргументы которые приведены в пользу этого тезиса также применимы к любому разработчику, который выступает значимой бизнес-функцией.
Я понимаю желания автора и по-факту в том же Яндексе для такой мотивации исключительно для лидов+ есть лидершип-бонус так называемый.
Но главное что меня жёстко триггерит: когда тимлид не раскрывая дедлайнов полностью перекладывает ответственность за задачу на плечи конкретного разработчика и изредко или ежедневно заглядывает к нему за плечо чтобы проверить стал ли он на шаг ближе к своему лидершип бонусу. С какой стати я должен брать на себя коммитменты вообще не понимаю входных данных самого коммитмента? Чтобы потом в случае фа..па я вообще не имел никакой защиты и лиду было проще со мной "попрощаться" чтоб прикрыть свою ж.пу?
Как будто тимлид настолько отчаялся от своей бесполезной функции прокси-менеджера, что пытается высосать из пальца хоть какое-то, пускай мнимое влияние на результат.
Картина когда никто не знает ни про дедлайны, ни про сроки, выглядит соблазнительной для того чтоб вписать в селфревью, но я вообще не верю в то, что такое будет работать в продуктовой команде где продукт почти никогда не подстраивается под реалистичные сроки и когда для конкуренции за грейдап тебе надо подстраивать сроки под продукт 95% времени.
Пусть он разделит риск с бизнесом, если продукт не принесёт прибыли, то человек получит меньше, но он всё равно получит свою заслуженную зарплату за работу.
Это не риск. Риск - это вероятность лишиться своей квартиры, к примеру. Готовы к этому?
Короче говоря, автор изобрёл 115 ФЗ для разрабов на минималках
Ну Agile же. Есть двух недельный спринт- на любую задачу срок 14 дней. За 14 дней можно 2 раза создать человечество. Спросите у биг-босса - Он подтвердит.
Есть подозрение, что затяжка сроков происходит, скажем, на 10% от ТЗ, причём это 10% которые нужны не сразу или потенциально вообще не нужны, или реально сложны в реализации, или временно могут выполняться вручную. То есть сроки планировать надо на первоочередную функциональность отдельно, на 10% отдельно - например на фазе тестовой эксплуатации или поддержки или развития.
Конечно, неудачная архитектура может сорвать последнюю стадию, но это уже другая проблема.
О, тут рассуждают разрабы про управление проектной деятельностью? Это те самые разрабы, которые топят за очень глубокие компетенции в кодинге и дрюкают друг друга на собесах бессистемно, чтобы почесать чсв? Отчегож эти самые люди считают, что без знаний/умений/навыков, в основе которых лежит накопленный человечеством материал, они в этом разбираются? А, точно, они же там где-то работали и что-то видели (но это ее точно). И, раз так, то их мнение - истина в последней инстанции. У автора неплохой материал, чуть сложноватый и требующий знания основ социального управления. Но ведь многие, когда не понимают, считают глупым не себя, а объясняющего, правда?
Вспомнилось нетленное «быстро, дёшево, качественно — выбирайте два из трёх».
Ну вот тут получается «дёшево, тщательно, время для работы будет выделяться по остаточному принципу и наличию вдохновения». «Быстро» принесли в жертву.
Но вообще, конечно, сроки бывают непредсказуемы в обе стороны. Помнится, хотели за две недели (ну или типа того, плюс-минус, не помню точно) проверить, реализуем ли принципиально прибор — а выкатили работающий образец. Получилось прямо даже смешно — я всё сделал «по феншую», а опытный девайс взял и заработал без сюрпризов. Прямо рехнуться можно — оказалось, действительно предусмотрел всё. Случай единичный, конечно, но всё же :) Фигак — и никакой доводки не потребовалось, попадание с первой попытки.
Интересная статья. Поднимает важные вопросы. От себя могу добавить, что даже рутинный труд (причем тоже можно применить не только к разработке), который ты выполнял множество раз, всё-равно немножечко отличается. И дьявол может быть в деталях. Даже для мелких подзадач. По этому на вопрос "когда будет готово n?", которое возникает в основном лишь при срочных заказах или срочных/авральных тасках в трекере, я, чтобы не врать, нередко отвечаю: если все пойдет по плану, то через 30 минут/любой другой промежуток времени, минимальный/оптимальный для выполнения поставленной задачи. А если возникнут подводные камни (или будет кто-нибудь над душой стоять и отвлекать каждые 10 минут), то может и вообще завтра только ждите результат/другой адекватный срок с учетом возникших проблем.
"Предположение - мать всех провалов" (с) Но без планирования в мире бизнеса все-равно никуда.
Дать тимлиду долю от проекта, а не от бизнеса, - это стагнация. Новый проект всегда имеет очень большие риски. Часто это вообще эксперименты. Либо проект будет год работать в минус перед тем как начать приносить прибыль. Таким образом, получив пару раз большую фигу вместо кругленькой суммы, тимлид помашет компании ручкой и уйдет в закат.
Когда говорят, что берутся риски и нужно это поощрять таким образом, забывают, что максимальный риск для того человека - потеря должности. А для бизнеса - банкротство и уголовка для собственников. Так что когда начнется такое разделение рисков, многие, думаю, откажутся
Все хорошо, но!…
Кто такие «разработчики»? Вы строитель или планы какие-то разрабатывайте?
/риторикв
Этот срок должен называться только тимлидом. Тимлидом должен быть очень опытный разработчик, и он может и даже должен консультироваться с членами команды по срокам, но сами сроки, которые у него получились, не должны нигде мелькать — ни в Jira, ни даже устно, их нигде не должно быть перед глазами
Такое возможно лишь тогда, когда тимлид отлично разбирается во всем проекте, чтобы давать какие-то реальные сроки. Это возможно лишь если проект небольшой и в большинстве своем написан самим тимлидом. Или же если тимлид тщательно смотрит все изменения в проекте, что с ростом команды становится практически невозможно.
И ещё вопрос - если сроки есть только в голове у тимлида, то как разработчику понять насколько детально он может погрузиться в задачу - можно ли сейчас зарефакторить тот самый класс или надо вставлять очередной костыль?
тимлида — не мерить KPI, а чувствовать, работает человек или симулирует. И если кажется, что что-то не так — очень важно сразу это сказать, даже если может показаться, что это пустое обвинение
Не очень понятно что значит "чувствовать" и "кажется". Если тимлид приходит к разработчику не с какими-то конкретными показателями, а с тем, что ему кажется, что эту задачу можно было бы сделать быстрее, то это, скорее всего, закончится конфликтом.
Вот только разработка часто не рисунок а чертеж. И даже совсем неопытный инженер сможет выполнить комплект чертежей очень сложного узла ядерного реактора, даже если никогда и не видел этого самого узла.
Всё просто разбивается на мелкие задачи: линию можешь провести? А квадрат? Дугу с заданной кривизной?
Вот тебе подробное описание - чертИ.
Мелкие задачи оцениваются в виртуальных сусликах (сравнительно "сложнее чем" "проще чем") - это оценка
Две недели следим за командой сколько сусликов будут закрыты, по итогу имеем референс и начинаем нарезать мелкие задачи и оценивать их выстраивая очередь задач - это бэклог.
Потихоньку начинаем закручивать гайки и спрашивать у команды "у вас все хорошо? Давайте ка думать как бы нам все улучшить" - это ретро
Считаем оценку всех задач, переносим ее на время, добавляем риски - это сроки.
Вы прослушали краткий очень вольный пересказ рецепта скрама.
Поздравляю вас, вы только, что описали принципы planing poker и как вычислять velocity команды. У меня вы свое время ушло 8-10 двухнедельных спринтера, перед тем как velocity команд стабилизировалось.
Именно, и чем опытнее команда и техлид - тем быстрее можно стабилизировать велосити.
И это в любом случае оценка, пусть не точная на старте, но оценка сроков.
Исходя из которой можно работать с заказчиком и командой для прогнозирования дедлайна.
И уже лучше чем - "ну ... Я же сказал завтра, чё ты всё время сегодня приходишь?"
Разработчики могут сравнивать себя с художниками, но бизнесу нужны токари. Поэтому при любой возможности получить адекватный результат в четкие сроки бизнес будет выбирать токарей вместо художников.
Сегодня мы видим это в low-code и no-code платформах, активному вайб-кодингу и так далее. Развитие этих инструментов бизнес будет поддерживать активно, потому что через них он получает приемлемый конечный результат с четкими сроками.
А художники постепенно становятся... Художниками. Голодными и с признанием после смерти :)
Это плохо. Человечество остаётся человечеством (культурным) именно благодаря художникам.
No coding как раз показывает скорость изменения бизнеса которому решение нужно прямо сейчас и на короткий срок. Через год будет сменено пять подходов и пятнадцать раз переписано всё, потому что поддерживать старое приложение (которому месяц) никто не сможет и не будет.
Ключевое тут - короткий срок.
Те кому нужна стабильность и поддержка в долгую - вайб кодинг воспринимают как игрушку для подростков, которые благодаря своей работоспособности и таланту, делают удивительные вещи, но одноразовые.
Как-то квантовые сроки
Ну если у разработчика нет сроков по созданию объектов, то откуда у заказчика обязанности по оплате в срок? Ну, блин, ну инфантилизм когда-то должен пройти.
"Вы знаете, я тут работаю вот работаю и что-то решил сроки не говорить и долю мне дайте".
Да, конечно. Две доли.
25 лет назад был изобретен Cynefin Framework. Первое, что мы делаем -- договариваемся с заказчиком, менеджером, коллегами, в каком домене сложности находится задача, а потом не нарушаем правил, царящих в домене. Если все согласны, что задача рутинная -- обговариваются сроки. Если есть над чем подумать -- разбивают на подзадачи, делают сроки плавающими. Если объективно недостаточно информации, чтобы вообще понять, решаема ли задача -- заказывают лишь исследование, но не продукт. И т.д.
Господи, какой детский сад.
Ну, к примеру давай добавим заказчика, который такой ждёт, а получиться ли у это "свободного художника" или у заказчика бизнес прогорит.
А где в статье риски!? А про них ни кто не знал!?
Бесполезно прогнозировать сроки у основного поддомена, с такой задачей даже ваш самый опытный разработчик, скорее всего, не сталкивался, а значит, будет как котёнок сначала тыкаться носом в стену, пытаясь решить задачу.
Тут можно воспользоваться методом Бобука-Бацека
https://www.youtube.com/watch?v=XUqiMEh2PMc
У разработчиков не должно быть сроков