Комментарии 85
История 1:
Вы вообще хоть когда-нибудь видели 20 летний легаси проект? Он работает да. И часто неплохо работает. Но там костыль на костыле и как и почему оно работает уже обычно никто не знает. Перетаскивать такое на другую платформу это пусть страданий и боли. Да-да писать only Win сейчас это тупик. Телефоны, маки без них проиграешь. В вашем примере трейдер точно хочет и то и другое.
Иногда надо говорить все, точка. Пришло время переписать. Если у бизнеса есть время и деньги на такое это же великолепно.
Срок жизни развивающегося проекта в 20 лет это уже перебор. За это время изменилось примерно все.
История 2:
Про басфактор вы тоже не слышали? Внутреннее обучение, лекции от Антона, митапы для поговорить. Да-да это все потеря денег и вообще разработчики работать должны, а не за пиццей обсудать уже сделанные вещи. Зато команда будет в курсе что почему и как сделано.
Если вам достался разработчик уровня FAANG используйте его правильно. Он на самом деле может клевые вещи делать.
История про архитектора Ивана:
Что это у вас за сеньеры которые не в курсе общего виденья? Это же их прямая работа. Знать на каком-то уровне всю или хотя бы большую часть кодовой базы своей команды разработки.
И опять тот же басфактор. Кто мешал потратить время на то чтобы сеньры разобрались во всем? Просто ставить им задачи из разных частей проекта. Будет не так быстро, зато басфактор вырастет. И увольнения пары человек можно будет не бояться.
Вы вообще хоть когда-нибудь видели 20 летний легаси проект? Он работает да. И часто неплохо работает. Но там костыль на костыле и как и почему оно работает уже обычно никто не знает. Перетаскивать такое на другую платформу это пусть страданий и боли. Да-да писать only Win сейчас это тупик. Телефоны, маки без них проиграешь. В вашем примере трейдер точно хочет и то и другое.
Иногда надо говорить все, точка. Пришло время переписать. Если у бизнеса есть время и деньги на такое это же великолепно.
Срок жизни развивающегося проекта в 20 лет это уже перебор. За это время изменилось примерно все.
История 2:
Про басфактор вы тоже не слышали? Внутреннее обучение, лекции от Антона, митапы для поговорить. Да-да это все потеря денег и вообще разработчики работать должны, а не за пиццей обсудать уже сделанные вещи. Зато команда будет в курсе что почему и как сделано.
Если вам достался разработчик уровня FAANG используйте его правильно. Он на самом деле может клевые вещи делать.
История про архитектора Ивана:
Что это у вас за сеньеры которые не в курсе общего виденья? Это же их прямая работа. Знать на каком-то уровне всю или хотя бы большую часть кодовой базы своей команды разработки.
И опять тот же басфактор. Кто мешал потратить время на то чтобы сеньры разобрались во всем? Просто ставить им задачи из разных частей проекта. Будет не так быстро, зато басфактор вырастет. И увольнения пары человек можно будет не бояться.
Ок, проясню немного, чтобы не плодить домыслы.
История 1: 20 лет было карьере Василия, а продукту было года 4, причем до него Василий с командой уже имели опыт написания АРМ для фьючерсного трейдинга, и тот, продукт, о котором идет речь, уже был переписанной версией с учетом архитектурных проблем и костылей. Ну а насчет желаний трейдеров работать со смартфона, — такое требование не имеет смысла, ведь трейдеры в данном случае это люди на зарплате, и работают исключительно со своих корпоративных рабочих станций. Разве что, могло бы иметь место какое-то простенькое веб-приложение для отчетности, чтобы главный трейдер и топ-менеджеры могли посматривать, но не более.
История 2: в данном конкретном случае не готовы были руководители к правильному использованию таких, как Антон. Но речь о том, как они потеряли шанс, а о том, как Антон, невзирая на это, использовал ситуацию по максимуму.
История 3: а кто сказал, что архитектор Сергей, имевший карт-бланш на процессы у себя, имел цель оптимизировать бас-фактор? Он тоже фармил свое CV. Снова таки, я говорю не о том, как бизнес дошел до такой жизни, а о том, как оперируя понятием ценности бизнесу, люди добивались своих целей. Да, неэтично, и эксплуатируя дыры.
История 1: 20 лет было карьере Василия, а продукту было года 4, причем до него Василий с командой уже имели опыт написания АРМ для фьючерсного трейдинга, и тот, продукт, о котором идет речь, уже был переписанной версией с учетом архитектурных проблем и костылей. Ну а насчет желаний трейдеров работать со смартфона, — такое требование не имеет смысла, ведь трейдеры в данном случае это люди на зарплате, и работают исключительно со своих корпоративных рабочих станций. Разве что, могло бы иметь место какое-то простенькое веб-приложение для отчетности, чтобы главный трейдер и топ-менеджеры могли посматривать, но не более.
История 2: в данном конкретном случае не готовы были руководители к правильному использованию таких, как Антон. Но речь о том, как они потеряли шанс, а о том, как Антон, невзирая на это, использовал ситуацию по максимуму.
История 3: а кто сказал, что архитектор Сергей, имевший карт-бланш на процессы у себя, имел цель оптимизировать бас-фактор? Он тоже фармил свое CV. Снова таки, я говорю не о том, как бизнес дошел до такой жизни, а о том, как оперируя понятием ценности бизнесу, люди добивались своих целей. Да, неэтично, и эксплуатируя дыры.
1. Ок. При таких вводных наверно и нет смысла.
Трейдеры на зарплате и снаружи нельзя? Я вижу точку для роста. Пустить всех желающих и брать с них процент. Не знаю потенциальных ограничений, но выглядит решаемо. И тогда уже и веб и все окупится.
2. Это проблема руководстсва и менеджеров, а не Антона. Он любит и умеет писать код и проектировать системы. Он этим и занимается. Бегать и организовывать всё остальное должны менеджеры. От него только подготовиться и рассказать другим разработчикам. Что-то еще требовать от разработчика в таком случае это лишнее.
3. Басфактор 1. Почему один человек все решает? Почему никто не в курсе что сеньеры не в курсе всего проекта и у них нет задач на разобраться и допилить доселе неизвестные им куски? Чем там вообще менеджеры занимаются? Почему все сложное свалено на одного, а остальные просто безвольные кодеры своих маленьких кусочков (не факт но очень похоже с виду)?
Как раз тут везде ключевое как бизнес дошел до такого. Это все назревает годами. Поправить можно пока не взорвалось. Везде фигурируют люди которые должны быть в курсе и должны тратить свое время на увеличение бас фактора.
Если таких людей много, то пора технических менеждеров заводить. Которые будут в курсе чем живет команда разработки. И которые должны ходить к руководству с рассказами что у нас один человек все знает и никого не пускает. Поправить надо.
Но фичи при этом будут пилиться медленнее, да и разработка станет дороже. Кажется что это главная проблема.
Трейдеры на зарплате и снаружи нельзя? Я вижу точку для роста. Пустить всех желающих и брать с них процент. Не знаю потенциальных ограничений, но выглядит решаемо. И тогда уже и веб и все окупится.
2. Это проблема руководстсва и менеджеров, а не Антона. Он любит и умеет писать код и проектировать системы. Он этим и занимается. Бегать и организовывать всё остальное должны менеджеры. От него только подготовиться и рассказать другим разработчикам. Что-то еще требовать от разработчика в таком случае это лишнее.
3. Басфактор 1. Почему один человек все решает? Почему никто не в курсе что сеньеры не в курсе всего проекта и у них нет задач на разобраться и допилить доселе неизвестные им куски? Чем там вообще менеджеры занимаются? Почему все сложное свалено на одного, а остальные просто безвольные кодеры своих маленьких кусочков (не факт но очень похоже с виду)?
Как раз тут везде ключевое как бизнес дошел до такого. Это все назревает годами. Поправить можно пока не взорвалось. Везде фигурируют люди которые должны быть в курсе и должны тратить свое время на увеличение бас фактора.
Если таких людей много, то пора технических менеждеров заводить. Которые будут в курсе чем живет команда разработки. И которые должны ходить к руководству с рассказами что у нас один человек все знает и никого не пускает. Поправить надо.
Но фичи при этом будут пилиться медленнее, да и разработка станет дороже. Кажется что это главная проблема.
Раз так хотите подискутировать о том, как решать задачу, обратную теме поста, то давайте, почему нет)
Решение с закручиванием гаек вроде этого https://m.habr.com/ru/post/501244/comments/#comment_21595022 кажется самым простым. В частности, технические менеджеры, которые прожимают нерадивых технарей, разводя стукачество, это шаг к тому, чтобы перестать требовать от программиста ценности бизнесу, а требовать исполнения конкретных задач.
Но вопрос в том, почему считаете, что это работает (даже ценой понижения темпа)? Все таки, программист же не траншеи копает?) Если бы зажимание в рамки работало, то все бы сидели на IBM Rational и аналогах. Почему-то же мир пошёл в другую сторону...
Не надо никого прожимать. И гайки закручивать не надо. И упаси боже никакого стукачества.
Все обсуждается в начале с теми кто все гребет под себя. Обычно люди достаточно адекватные и когда к ним придут с вопросом Почему у тебя команда не разбирается в проекте? они расскажут причины. И дальше можно обсудить что делать для изменения ситуации. Обычно вполне хватает снижения скорости разработки новых фич и выделения времени на рефакторинг и на разобраться. В конкретном случае человек может запросить что-то еще, надо думать и обсуждать именно его предложение как решить эту проблему. Но да для этого нужен человек со стороны который будет в курсе что в команде происходит. Обычно это технический менеджер. Допускаю что должность может называться по другому.
Люди которые принципиально не хотят отдавать компетенции чтобы быть незаменимыми откровенно вредят бизнесу. Тут уже не стукачество, а спасение команды разработки. В таком коллективе все нездоровое. Спасать срочно надо.
Я наоборот за расширение рамок.
Если у вас есть выдающиеся разработчики, пусть рассказывают другим о своих лучших решениях. Да и вообще об архитектурных решениях. Выдайте им время на подготовку к рассказу и уговорите что это полезно. И организуйте все.
Если у вас есть сеньеры идеально знающие свой уголок проекта, то пусть тратят свое время чтобы разобраться в других частях. Пока не разберутся они будут приносить меньше пользы бизнесу. Но зато басфактор растет. Компетенции распределяются.
Я про устоявшиеся и достаточно большие и сложные проекты. Стартапы естесвенно не так работают. Там делаем, получаем финасирование, переделываем заново и снова переделываем. И все это за год или меньше. Гоним вперед до вырастания в большой и сложный проект или до продажи. А потом уже как обычно. Басфактор, менеджеры, компетенции.
Все обсуждается в начале с теми кто все гребет под себя. Обычно люди достаточно адекватные и когда к ним придут с вопросом Почему у тебя команда не разбирается в проекте? они расскажут причины. И дальше можно обсудить что делать для изменения ситуации. Обычно вполне хватает снижения скорости разработки новых фич и выделения времени на рефакторинг и на разобраться. В конкретном случае человек может запросить что-то еще, надо думать и обсуждать именно его предложение как решить эту проблему. Но да для этого нужен человек со стороны который будет в курсе что в команде происходит. Обычно это технический менеджер. Допускаю что должность может называться по другому.
Люди которые принципиально не хотят отдавать компетенции чтобы быть незаменимыми откровенно вредят бизнесу. Тут уже не стукачество, а спасение команды разработки. В таком коллективе все нездоровое. Спасать срочно надо.
Я наоборот за расширение рамок.
Если у вас есть выдающиеся разработчики, пусть рассказывают другим о своих лучших решениях. Да и вообще об архитектурных решениях. Выдайте им время на подготовку к рассказу и уговорите что это полезно. И организуйте все.
Если у вас есть сеньеры идеально знающие свой уголок проекта, то пусть тратят свое время чтобы разобраться в других частях. Пока не разберутся они будут приносить меньше пользы бизнесу. Но зато басфактор растет. Компетенции распределяются.
Я про устоявшиеся и достаточно большие и сложные проекты. Стартапы естесвенно не так работают. Там делаем, получаем финасирование, переделываем заново и снова переделываем. И все это за год или меньше. Гоним вперед до вырастания в большой и сложный проект или до продажи. А потом уже как обычно. Басфактор, менеджеры, компетенции.
С нетерпением ждём статей: «Как я ушёл из программирования, чтобы не решать задачи бизнеса», «Как делать карьеру доставщика пиццы, изучая Кийосаки и BrainFuck» и «Ты ничего не должен бизнесу и это взаимно».
Статьи хорошие. Показывают, что вы начинаете задумываться об этих вещах. Правда вот в первой было несколько странных замечаний:
- Авиационный инженер, вынужден думать о бизнесе. Почему, например, сейчас много широко-физюляжных самолетов, которые летают медленно-медленно, а нет больше чего-нибудь вроде конкорда? Да потому, что дизайн современных самолетов — это образец максимизации прибыли. Инженер — "художник я так вижу и никому не обязан" в авиации долго не продержится. Хотя бы на инженеров Маска посмотрите, не думают они о бизнесе?
- Инженер, строящий мост (напр. главный инженер) — только об этом и думает. О том как сделать мост дешевле, как ввести его в эксплуатацию быстрее и как на нем научит себя и персонал делать это лучше для следующего моста.
- Художник, рисующий на коробке выполняет заказ от отдела маркетинга. Это вроде как по аналогии — мид девелопер. А вот если он руководитель студии, то получается кто-то типа Темы Лебедева — и опять же думает о бизнесе.
- Врач хирург очень даже думает о бизнесе, особенно если у него частная практика. Возможно в РФ это не так наглядно, но в США это очень и очень актуально. Вам будут прописывать препараты, за которые врач получает комиссию, вам будут назначать обследования, которые не обязательны, но за них практика или госпиталь получают доп. оплату.
Все три истории, приведенные здесь, это образец того, что происходит при разваливающемся руководстве.
- История #1 — проблема в том, что судя по вашему описанию для технического руководителя нет никого, кто бы мог проверить его утверждения и разобраться в том, что он предлагает. Часто в таких ситуациях крупные компании проводят анализ проекта и нанимают внешних контракторов для аудита.
- История #2 — умение продавать себя и свои решения — ключевое отличие тех, у кого будет карьера и тех, у кого ее скорее всего не будет. Антон молодец, а опять же проблема в том, что руководитель Антона не занимался долгосрочным планированием.
- История #3 — с Иваном, опять та же самая проблема, что и с Антоном. Руководитель не озаботился тем, чтобы выполнять свои должностные обязанности с обзавестись долгосрочным планом поддержки продукта и развития команды.
И да истории показывают, что бывают организации где не думают о бизнесе (о деле — если по-русски). И да, там можно делать карьеру. И да, есть интерес бизнеса и есть интерес самого сотрудника и не всегда они совпадают. Но чаще всего, на моем опыте, в таких организациях идет процесс медленного гниения. Новые клиенты не приходят, старые кое-как тянутся и вот-вот уйдут к конкуренту. На мой вкус — мрак, но кому-то нравится.
В общем позвольте с вами не согласиться. Бизнес компания существует для бизнеса. Т.е. деловая группа людей (вся группа) существует для дела (бизнес — это ведь дело).
Весь смысл этого мероприятия (компании) в том, что в идеале собираются единомышленники, чтобы делать то, что они считают правильным (общее дело). И каждый из них приносит пользу в соответствии со своими умениями и способностями. А если кому-то из них, не нравится общее дело — то ведь проблема-то не в деле? Мало ли на свете тех вещей, которые надо сделать?
В том то и суть, что одно дело в идеале. А другое, — как происходит по факту. Многие ЛПР в бизнесе могут заменить практически любого подчиненного, и за счет этого дыры латаются, а недобросовестные сотрудники выводятся на чистую воду при погружении в тему руководства. А вот с ит это не работает. Увы.
Почему ИТ — исключение?
Потому, что в нетехнологическом бизнесе, как правило, основатель или СЕО может прийти, согнать любого сотрудника (оператора, маркетолога, продажника, а, почитав мануалы недельку, даже юриста и бухгалтера) с его рабочего места, и более-менее сносно его подменить. А вот сесть и пофиксить баг в коде как-то не особо выйдет. Или считаете по-другому?
Я лично считаю по-другому, да. Попробуйте "сносно подменить" актера на съемочной площадке. Или переводчика с китайского. Или преподавателя йоги.
По сути, все 3 примера о профессиях, где обладатель профессии практически полностью контролирует цепочку создания ценности и может зарабатывать на жизнь без начальников и подчиненных (тренер йоги, переводчик с китайского), или сам является брендом (владеет в некотором роде капиталом), как актёр. Это несколько не о том, что я имел в виду. Понятно, что можно нагенерить исключений и без таких ограничений, как, например, хозяину ночного клуба будет очень сложно заменить стриптизершу. Но, все же, моей целью было передать общий посыл, а не учесть все исключения
Но, все же, моей целью было передать общий посыл, а не учесть все исключения
Так я про ваш "общий посыл" и говорю. Подменить любого квалифицированного специалиста можно только обладая квалификацией, и странно ожидать, что владелец горного производства умеет управлять шагающим экскаватором.
Так важно ж не «уметь управлять шагающим экскаватором», а «уметь отличить человека, который им хорошо управляет от того, кто управляет плохо».
Это гораздо проще и работает даже с актёрами, до какой-то степени.
А вот с программистами — не работает. Возьмите 10 хороших програмистов и 10 плохих, перемешайте их, посадите рядком и дайте на них посмотреть несециалисту с целью отобрать лучших. Ничего не выйдет. Даже и программист может сходу не понять.
Самая ужасная, для бизнеса, беда: в том, что дурак — не может быть хорошим программистом. А умный — может максимизировать любой критерий, который просто оценивать, в свою пользу.
Это гораздо проще и работает даже с актёрами, до какой-то степени.
А вот с программистами — не работает. Возьмите 10 хороших програмистов и 10 плохих, перемешайте их, посадите рядком и дайте на них посмотреть несециалисту с целью отобрать лучших. Ничего не выйдет. Даже и программист может сходу не понять.
Самая ужасная, для бизнеса, беда: в том, что дурак — не может быть хорошим программистом. А умный — может максимизировать любой критерий, который просто оценивать, в свою пользу.
Так важно ж не «уметь управлять шагающим экскаватором», а «уметь отличить человека, который им хорошо управляет от того, кто управляет плохо».
Написано было "Потому, что в нетехнологическом бизнесе, как правило, основатель или СЕО может прийти, согнать любого сотрудника [...] с его рабочего места, и более-менее сносно его подменить.". С этим тезисом я и спорил.
А вот с программистами — не работает.
Это много с кем не работает.
Это много с кем не работает.Теоретически — да, а практически — не совсем: гениального авиаконструктора вы, глядя на него, от обычного инжинера не отличите… но их нужно-то не немного и можно смотреть на репутацию.
А вот уже обычного качественного инжинера от долбоёба, который всё неправильно рассчитывает — вы отличить можете.
А вот в ИТ-индустрии… фактически весь отдел для вас — чёрный ящик.
А вот уже обычного качественного инжинера от долбоёба, который всё неправильно рассчитывает — вы отличить можете.
Я? С чего вы взяли?
Наш генеральный не раз говорил мне (я тимлид): "мне не нужны гении, мне нужны рядовые. Я плачу не за генальность, а за скорость разработки".
И что-то мне кажется — таких как он чуть меньше чем все.
В нашей фирме директор может родить идею, детально её проработать, объяснить, а при необходимости и реализовать. Но чем больше разрастается фирма, тем больше задач делегируется, естественно. Остаётся только рождение идей и проработка, если продакты не справляются. Но это — скорее исключение, да.
Авиационный инженер, вынужден думать о бизнесе. Почему, например, сейчас много широко-физюляжных самолетов, которые летают медленно-медленно, а нет больше чего-нибудь вроде конкорда?
Когда инженер не думает о бизнесе, он строит SR-71. А когда думает, самолеты падают, потому что экономят на дублирующих системах
Инженер, строящий мост (напр. главный инженер) — только об этом и думает. О том как сделать мост дешевле, как ввести его в эксплуатацию быстрее и как на нем научит себя и персонал делать это лучше для следующего моста.
Каким образом главный инженер будет получать прибыль с того, что этот мост функционирует? Сделает проезд платным и будет получать по копейке с каждого рубля?
Художник, рисующий на коробке выполняет заказ от отдела маркетинга. Это вроде как по аналогии — мид девелопер. А вот если он руководитель студии, то получается кто-то типа Темы Лебедева — и опять же думает о бизнесе.
Так это прямая обязанность художника — нарисовать так, чтобы продукт лучше продавался. Только вот пример был про то, что быть художником — это порыв души, а не мечтать увеличить владельцу бизнеса продажи хлопьев.
Врач хирург очень даже думает о бизнесе, особенно если у него частная практика. Возможно в РФ это не так наглядно, но в США это очень и очень актуально. Вам будут прописывать препараты, за которые врач получает комиссию, вам будут назначать обследования, которые не обязательны, но за них практика или госпиталь получают доп. оплату.
Мои знакомые врачи стали врачами, потому что хотели людей лечить, а не чтобы бумажки заполнять или денег заработать.
Не спорьте, горячие эстонские парни. Достаточно сопоставить два факта:Врач хирург очень даже думает о бизнесе, особенно если у него частная практика. Возможно в РФ это не так наглядно, но в США это очень и очень актуально. Вам будут прописывать препараты, за которые врач получает комиссию, вам будут назначать обследования, которые не обязательны, но за них практика или госпиталь получают доп. оплату.Мои знакомые врачи стали врачами, потому что хотели людей лечить, а не чтобы бумажки заполнять или денег заработать.
1. Лидеры в рейтинге готовности к эпидемии 2019го года — США и Великобритания (в этом порядке).
2. Лидеры по количеству умерших — также США и Великобритания (в этом порядке).
И да — это прекрасно кореллирует с тем, что в США и Великобритании «врач хирург очень даже думает о бизнесе», всё правильно.
Иначе результаты были бы другими.
Так что лучше сюда врачей не привлекать — иначе сильно далеко уйдёте от темы.
Что можно сделать?Свалить.
"Василий… дорос от младшего программиста до руководителя департамента.… И все еще пописывал код, чтобы оставаться в форме."
Зашел я как-то в Пятерочку за помидорами, а их не завезли! И бананы гнилые оказались — ну что такое-то??!!! А потом смотрю: Лидия Ивановна — директор магазина (доросла с кассира, между прочим — хваткая женщина!) сидит на кассе, ну по-простому, по-свойски — былое вспомнить, да кассирам помочь.
Тут мне всё и понятно стало. Не хожу теперь в тот магазин.
Краткий пересказ «Бизнес тебя использует, а ты будь хитрее и используй его».
О, я как раз в роли Ивана сейчас. Только мне никто и ничего не предлагает, а на мои запросы отвечают — ну не будет тебя, закроем проект и всё.
Не хватает историй про то, как Валера разобравшись в бизнесе, рассказал заказчику, что тому уже год пудрят мозги и ушел работать к нему напрямую. А Гоша разобравшись в бизнесе, открыл свою фирму, уведя у прежнего работодателя часть клиентов.
Наука — это удовлетворение своего любопытства за государственный счёт
Был один кейс у знакомых:
— Получили заказ на разработку, срок — 12 месяцев. Работу поручили команде под управлением гениального (вот серьёзно) программиста Феди. За 6-7 месяцев было готово процентов 80 функционала. И тут вышла новая перспективная технология/ЯП. Федя пошёл к руководству и расписав преимущества технологии предложил переписать на ней с нуля почти готовое решение. Не знаю, чем он мотивировал — повышением качества, скорости безопасности, тем что руководству премию дадут, будут уступать место в автобусе или ещё что… В общем, приняли решение остановить разработку, за месяц изучить новую технологию и потом на ней реализовать решение.
Через 3-4 месяца предсказуемо случился факап: технология оказалась сложнее, решение не совсем подошло и тд. Пришлось увольнять Федю, срочно созывать всех более-менее свободных программистов и обещать им премии если они успеют вовремя
Был один кейс у знакомых:
— Получили заказ на разработку, срок — 12 месяцев. Работу поручили команде под управлением гениального (вот серьёзно) программиста Феди. За 6-7 месяцев было готово процентов 80 функционала. И тут вышла новая перспективная технология/ЯП. Федя пошёл к руководству и расписав преимущества технологии предложил переписать на ней с нуля почти готовое решение. Не знаю, чем он мотивировал — повышением качества, скорости безопасности, тем что руководству премию дадут, будут уступать место в автобусе или ещё что… В общем, приняли решение остановить разработку, за месяц изучить новую технологию и потом на ней реализовать решение.
Через 3-4 месяца предсказуемо случился факап: технология оказалась сложнее, решение не совсем подошло и тд. Пришлось увольнять Федю, срочно созывать всех более-менее свободных программистов и обещать им премии если они успеют вовремя
Пришлось увольнять Федю
В этой истории я совсем не удивлюсь, если гениальный Федя после увольнения ушел куда-нибудь на повышение, возможно даже связанное с той самой технологией. И возможно даже реализовал её куда более успешно у других людей.
Так что да, если ЛПР не может здраво оценивать риски от идей «все переписать» — бизнесу это рано или поздно выходит боком. А вот дающим эти идеи — не обязательно, более того, им с точки зрения их личной выгоды может быть крайне выгодно эти идеи давать и продавливать.
Вообще-то достаточно было спросить коллег Феди что они думают о новой технологии.
Скорее всего не помогло бы. Разве что, после ухода Феди можно было бы пробить его коллег на чувство вины, что тоже бы делу не помогло.
Ведь в пользу поддержки идей Феди (если под коллегами подразумеваем его подчиненных) сыграло бы два фактора.
1) В коллективах программистов авторитет сильно коррелирует с техническим уровнем (в чем причины этого, — тема для отдельной статьи). И, скорее всего Федя стал руководителем не за победы в подковерных войнах, а за реальное экспертное превосходство. Соответственно, против, скорее всего, мог бы выступить только человек с амбициями занять место Феди, но таких, по моему опыту, в коллективах программистов мало. И, поэтому, большинство бы поддержало его. Ведь, если все вокруг уважают Федю, и признают его превосходство, то подвергать его идеи сомнению при менеджере, — хороший шанс прослыть выскочкой и идиотом для всего коллектива.
2) Я хз, был ли в доле или с большим завязанным на результат бонусом Федя, но, скорее всего, у его коллег таковых завязок не было точно. И поэтому, выбирая между «получать пол года зп за рутинный труд на известных технологиях» и «за пол года получить ту же зп и при этом изучить новую крутую технологию под менторингом Феди, пусть и с риском для бизнеса», выбор был бы очевиден.
Ведь в пользу поддержки идей Феди (если под коллегами подразумеваем его подчиненных) сыграло бы два фактора.
1) В коллективах программистов авторитет сильно коррелирует с техническим уровнем (в чем причины этого, — тема для отдельной статьи). И, скорее всего Федя стал руководителем не за победы в подковерных войнах, а за реальное экспертное превосходство. Соответственно, против, скорее всего, мог бы выступить только человек с амбициями занять место Феди, но таких, по моему опыту, в коллективах программистов мало. И, поэтому, большинство бы поддержало его. Ведь, если все вокруг уважают Федю, и признают его превосходство, то подвергать его идеи сомнению при менеджере, — хороший шанс прослыть выскочкой и идиотом для всего коллектива.
2) Я хз, был ли в доле или с большим завязанным на результат бонусом Федя, но, скорее всего, у его коллег таковых завязок не было точно. И поэтому, выбирая между «получать пол года зп за рутинный труд на известных технологиях» и «за пол года получить ту же зп и при этом изучить новую крутую технологию под менторингом Феди, пусть и с риском для бизнеса», выбор был бы очевиден.
Ну если суммарный опыт коллектива превышает опыт Феди, то наверняка там найдётся кто-то кто уже использовал эту технологию, либо у кого-то есть друг, который использовал. И если технология кривая и неудачная, то он вряд ли бы порекомендовал её.
Вообще авторитаризм — одна из основных проблем в неразвитых коллективах. По идее, Федя должен лишь служить арбитром в спорах, а не являться единственным источником истины.
Особенно это страшно, когда Федя работает лет 20 в компании и по сути не обладает диверсифицированным опытом, но при этом является «уважаемым» человеком.
Обычно, именно такие люди склонны к авантюрам — становиться скучно, тянет получить опыт, но не в других компаниях/проектах (где это может быть более оправданно), а именно там где простят все ошибки.
Менджмент просто обязан следить, чтобы он не мог давить своим авторитетом на коллег.
Вообще авторитаризм — одна из основных проблем в неразвитых коллективах. По идее, Федя должен лишь служить арбитром в спорах, а не являться единственным источником истины.
Особенно это страшно, когда Федя работает лет 20 в компании и по сути не обладает диверсифицированным опытом, но при этом является «уважаемым» человеком.
Обычно, именно такие люди склонны к авантюрам — становиться скучно, тянет получить опыт, но не в других компаниях/проектах (где это может быть более оправданно), а именно там где простят все ошибки.
Менджмент просто обязан следить, чтобы он не мог давить своим авторитетом на коллег.
Ну если суммарный опыт коллектива превышает опыт Феди, то наверняка там найдётся кто-то кто уже использовал эту технологию, либо у кого-то есть друг, который использовал
На чём основано такое утверждение? У новых технологий «боевого опыта» обычно не находится ни у кого, а если и находится — то под другие обстоятельства, а опыт из серии «друг коллеги брата жены» (то есть не опыт, а слухи в стиле ОБС) нормальными людьми всерьез приниматься не будет.
И если технология кривая и неудачная, то он вряд ли бы порекомендовал её.
А кто вам сказал, что технология кривая и неудачная?
Или кто вам сказал, что явно видно, что технология не подойдет к имеющемуся use case? Вы всерьез полагаете, что это вот так сразу само по себе видно? Нет, это вещи, над прояснением которых нужно вдумчиво (и зачастую еще и долго) работать.
Авторитаризм тут вообще не при чём. Стоит опросить любое количество разработчиков по любой новой технологии, плюс-минус подходящей к текущей ситуации — и быстрые ответы без долгого детального разбора полётов (с написанием proof of concept, а то и нескольких) будут все без исключения сводится к «мне нравится» или «мне не нравится». Какой процент тех или других ответов будет — вообще не важно, всё равно это всё голословно.
Именно поэтому нужно в первую, вторую, и даже третью очереди — анализировать риски, особенно исчислимые риски. И если в первом приближении всё ок — то, по необходимости, еще и второе и последующие приближения оценивать, через исследовательские proof of concept.
Так называемые «новые технологии» это как правило часто, что изобретено 5 лет назад, а то и раньше. Более того, опыт в похожих технологиях и общий разработческий опыт тоже полезен.
Скажем если я раньше работал с batch processing и новая технология тоже связана с batch processing, то мой опыт очень даже релевантен.
На счёт ОБС вы не правы. Реальный опыт, а не теоретическое философствование, крайне важен. Более того, бывают технологии настолько неудачные, что они не применимы ни при каких обстоятельствах.
Вы только что назвали всех разработчиков поверхностными и некомпетентными. Это как-то очень спорное утверждение.
Анализировать риски несомненно надо, но это опять же это не бедный Федя, кто будет всем заниматься и писать все proof of concepts, а вся команда должна быть вовлечена. Так и только так.
Скажем если я раньше работал с batch processing и новая технология тоже связана с batch processing, то мой опыт очень даже релевантен.
На счёт ОБС вы не правы. Реальный опыт, а не теоретическое философствование, крайне важен. Более того, бывают технологии настолько неудачные, что они не применимы ни при каких обстоятельствах.
Стоит опросить любое количество разработчиков по любой новой технологии, плюс-минус подходящей к текущей ситуации — и быстрые ответы без долгого детального разбора полётов (с написанием proof of concept, а то и нескольких) будут все без исключения сводится к «мне нравится» или «мне не нравится». Какой процент тех или других ответов будет — вообще не важно, всё равно это всё голословно.
Вы только что назвали всех разработчиков поверхностными и некомпетентными. Это как-то очень спорное утверждение.
Именно поэтому нужно в первую, вторую, и даже третью очереди — анализировать риски, особенно исчислимые риски. И если в первом приближении всё ок — то, по необходимости, еще и второе и последующие приближения оценивать, через исследовательские proof of concept.
Анализировать риски несомненно надо, но это опять же это не бедный Федя, кто будет всем заниматься и писать все proof of concepts, а вся команда должна быть вовлечена. Так и только так.
Подскажите где берется время на исследования, proof of concept, etc?
Вводная: обычный бизнес, то есть колво разрабов на минимум, на расширение отдела нет денег, хотелки расписаны на месяцы вперед. Не лукойл, не гугл.
Подскажите где берется время на исследования, proof of concept, etc?
Нигде не берется, при таких вводных самое нормальное (и чаще всего применяемое) — это «ничего не трогаем и не меняем, если вообще можем ничего не трогать и не менять».
Ну или факапы и феди, если без предварительной подготовки таки регулярно чего-то переписывают.
Это вообще ничего не даёт. Особенно если условный Федя — самый опытный, но даже если и нет — всё равно ничего не даёт.
ЛПР никогда нет может оценить такой риск. Если он действительно ЛПР, а не менеджер чего-то там.
Ну кстати говоря, если там работает старое доброе правило, что 80 процентов работы делается за 20 процентов времени, то фейл бы их ждал в любом случае :)
Насколько я понял, во всех трех рассказах программисты «думали о бизнесе...», о своем бизнесе. :-)
Вообще-то проблема в программировании в том, что нет простых и понятных метрик для «хорошего кода».
Т.е. кода, который легко расширяется и легко поддерживается.
Более-менее отдаленно похожее на правду можно выудить из «процента покрытия тестами».
Да и то, очень отдаленно.
Т.е. грубо говоря, чтобы «управлять программистами», нужно понимать что и как они пишут.
А работающий в данный момент времени продукт ни о чем не говорит.
Т.к. может оказаться, что стоимость изменений сопоставима с «переписыванием с нуля».
Но мало кто «вот прям щас» дать точную оценку не сможет.
Поэтому и получаем «программист должен решать проблемы бизнеса».
Т.е. оценивать не только стоимость изменений, но и говорить, какие изменения наиболее выгодные.
Обычно бизнес прибегает и кричит, как в анекдоте, «сделайте мне кастрацию»! :-)
Вообще-то проблема в программировании в том, что нет простых и понятных метрик для «хорошего кода».
Т.е. кода, который легко расширяется и легко поддерживается.
Более-менее отдаленно похожее на правду можно выудить из «процента покрытия тестами».
Да и то, очень отдаленно.
Т.е. грубо говоря, чтобы «управлять программистами», нужно понимать что и как они пишут.
А работающий в данный момент времени продукт ни о чем не говорит.
Т.к. может оказаться, что стоимость изменений сопоставима с «переписыванием с нуля».
Но мало кто «вот прям щас» дать точную оценку не сможет.
Поэтому и получаем «программист должен решать проблемы бизнеса».
Т.е. оценивать не только стоимость изменений, но и говорить, какие изменения наиболее выгодные.
Обычно бизнес прибегает и кричит, как в анекдоте, «сделайте мне кастрацию»! :-)
Более-менее отдаленно похожее на правду можно выудить из «процента покрытия тестами».
Я несколько лет назад участвовал в проекте, где на ранних этапах программисты решили погрузиться в TDD за счёт компании. Покрытие тестами было 100%. Делать оно практически ничего полезного не делало — половину тестов можно было выбросить и заменить тайпскриптом, из оставшихся еще треть тестов можно было выкинуть вместе с кодом, так как это всё был оверинжиниринг, порожденный неопытностью авторов в написании тестов (не смогли отдельные вещи покрыть на 100% легко, и начали усложнять архитектуру на ровном месте, чисто чтоб добить покрытие).
Ну и никаких тестов, кроме юнит-тестов, на проекте не было вообще. Потому что «продали» руководству юнит-тесты, на них ушло время, а на всё остальное — не осталось.
Делать оно практически ничего полезного не делало — половину тестов можно было выбросить и заменить тайпскриптом,
Из этой фразы можно сделать вывод, что тайпскрипт ничего полезного не делает. :)
Почему же?) Из этой фразы можно лишь сделать вывод, что есть некая работа, которую делает тайпскрипт или половина тестов (в зависимости от того, какой путь выберет разработчик). О целесообразности или полезности этой работы ни слова.
Написано, что практически всё было бесполезно, включая то, что можно заменить на тайпскрипт
Делать оно практически ничего полезного не делало
Фраза относится к предыдущему существительному, т.е. к 100% покрытию тестами.
Я понял. Мне не понятно зачем заменять 50% покрытия тестами на тайпскрипт, если пользы нет? Или эта такая квантовая польза: если подтверждают корректность программы тесты, то это подтверждение бесполезно, а если тайпскрипт, то полезно?
Скажем так, заменить половину юнит-тестов на тайпскрипт — это, применительно к той ситуации, равнозначно уменьшению кода тестов примерно вдвое. К коду проекта ничего существенного не добавляется, потому что сложных типов нет совсем. Я, собственно, об этом пишу именно потому, что именно это я и сделал на практике — прикрутил тайпскрипт в сборку, написал несколько простых interface и type, и просто удалил половину тестов.
То есть, сидеть покрывать типизацию аргументов юнит-тестами — это было плохое трудоемкое решение, создавшее много работы на ровном месте.
То есть, сидеть покрывать типизацию аргументов юнит-тестами — это было плохое трудоемкое решение, создавшее много работы на ровном месте.
В такой интерпретации понятно. Спасибо.
А покрытие какое стало после этого? Просто одно дело, когда функция написана с активным использованием приведений типов и юнит-тесты тупо проверяли, что результат при sum(1, 2) равен результату при sum("1", 2) и sum("1", "2") и другое если флоу функций были разными при разных типах параметров: передали строку — обрабатываем как CSS селектор, передали DOM элемент — обрабатываем как DOM и т. п.
Я не говорю, что процент покрытия дает точную оценку. Но от неё (процента покрытия) еще как-то можно отталкиваться. Грубо говоря, если что-то измениться, то какие-нибудь тесты упадут.
Выкинув юнит-тесты на мороз, как менеджер сможет оценить сколько потребуется времени на внесение изменений, если вся команда «уйдет» и будет набрана новая.
Понятно, что ситуация утрированная. Но я, как минимум с такой столкнулся.
Пришел на легаси проект, откуда уволились все программисты (был вопрос денег, перестали платить премии). Большая половина тестов была поломана, вроде бы как года три уже.
Документация описывала, состояние пятилетней давности. БД вообще никто никогда не описывал.
Внедряли новый функционал, который не был дописан.
В общем все те, кто кричит «юнит-тесты не нужны», я бы посадил на этот проект без права увольнения.
P.S. Раньше этот проект сопровождали 3-5 разработчиков. Сейчас я один. Благо новых фичь больше не было. Только правка багов. Сейчас взяли команду, которая переписывает все с нуля.
Думаю будет такое же дремучее легаси, но там хотя бы фронт-енд и бакенд разделены.
Выкинув юнит-тесты на мороз, как менеджер сможет оценить сколько потребуется времени на внесение изменений, если вся команда «уйдет» и будет набрана новая.
Понятно, что ситуация утрированная. Но я, как минимум с такой столкнулся.
Пришел на легаси проект, откуда уволились все программисты (был вопрос денег, перестали платить премии). Большая половина тестов была поломана, вроде бы как года три уже.
Документация описывала, состояние пятилетней давности. БД вообще никто никогда не описывал.
Внедряли новый функционал, который не был дописан.
В общем все те, кто кричит «юнит-тесты не нужны», я бы посадил на этот проект без права увольнения.
P.S. Раньше этот проект сопровождали 3-5 разработчиков. Сейчас я один. Благо новых фичь больше не было. Только правка багов. Сейчас взяли команду, которая переписывает все с нуля.
Думаю будет такое же дремучее легаси, но там хотя бы фронт-енд и бакенд разделены.
Ну так и я столкнулся, я ж про это и написал. Прихожу на проект, проект на стадии «больше чем proof of concept, меньше чем MVP». Покрытие тестами — 100%. Ничего, кроме юнит-тестов — нет. Оригинальные разработчики благополучно свалили в закат. И что в итоге?
В проекте as is никакого бизнес-смысла нет — его еще пилить и пилить до MVP. Тесты естественно будут ломаться, потому что функционал надо сильно развивать. Проект неплохо и даже излишне задокументирован, вот только смысла в этом никакого нет, потому что см. выше — код as is никакой бизнес-ценности не имеет еще пока.
Я в этой ситуации не нашел ничего, от чего можно бы было отталкиваться — всё, что я увидел — это что было проделано море совершенно бесполезной работы, часть плодов которой просто не была востребована (документация), часть я благополучно выкинул сам при последующем допиливании, и еще часть переписали коллеги в ходе дальнейшего развития, после того, как я разгрёб самые первые завалы и ушел разгребать аналогичные в другом проекте.
Не всякое покрытие одинаково полезно, я вот о чем.
В проекте as is никакого бизнес-смысла нет — его еще пилить и пилить до MVP. Тесты естественно будут ломаться, потому что функционал надо сильно развивать. Проект неплохо и даже излишне задокументирован, вот только смысла в этом никакого нет, потому что см. выше — код as is никакой бизнес-ценности не имеет еще пока.
Я в этой ситуации не нашел ничего, от чего можно бы было отталкиваться — всё, что я увидел — это что было проделано море совершенно бесполезной работы, часть плодов которой просто не была востребована (документация), часть я благополучно выкинул сам при последующем допиливании, и еще часть переписали коллеги в ходе дальнейшего развития, после того, как я разгрёб самые первые завалы и ушел разгребать аналогичные в другом проекте.
Не всякое покрытие одинаково полезно, я вот о чем.
Я был в такой же ситуации, кроме "переписывать с нуля".
Знаете что призойдет чуть позже? Когда владелец решит, что "все нормально", будут уволены самые дорогие разрабы, колво фичреквестов будет расти каждый день, а за баги введут штрафы.
А работающий в данный момент времени продукт ни о чем не говорит
Не ожидал встретить такое здесь.
И отжал бизнес по-максимуму.
аж поперхнулся. Прям отжал бизнес?
По моему все эти конфликты восходят к Марксу.
Бизнес — (толстый дядька в цилиндре) хочет денег, чтобы сидеть в шезлонге и потягивать мартини, и он с удовольствием бы обошелся без программиста.
Программист — (паренек в джинсах и майке) хочет развлекаться за счет дядьки в цилиндре. И он с удовольствием бы занимался своими проектами или просто исследованиями если бы деньги падали с неба.
Данный конфликт фундаментален, так что можно только писать статьи-рецепты как перетянуть одеяло в одну сторону. Теперь ждем статью «Как программиста заставить решать задачи бизнеса, так чтобы он думал, что делает карьеру»..
Бизнес — (толстый дядька в цилиндре) хочет денег, чтобы сидеть в шезлонге и потягивать мартини, и он с удовольствием бы обошелся без программиста.
Программист — (паренек в джинсах и майке) хочет развлекаться за счет дядьки в цилиндре. И он с удовольствием бы занимался своими проектами или просто исследованиями если бы деньги падали с неба.
Данный конфликт фундаментален, так что можно только писать статьи-рецепты как перетянуть одеяло в одну сторону. Теперь ждем статью «Как программиста заставить решать задачи бизнеса, так чтобы он думал, что делает карьеру»..
Мне кажется, что дискуссия заходит в тупик. Решать или не решать задачи бизнеса — это вопрос не о деньгах, а о власти. Ведь власть — это и есть право решать значимые для бизнеса вопросы, неся за это персональную ответственность за результаты принятых решений. Естественно, получая при этом несравненно большие объем и качество различных благ.
Проблема в том, что потребность во власти ощущают не более 5-7 (максимум 10) процентов от общего числа людей. Поэтому среди любых специальностей, в том числе среди программистов, встречаются люди, которым интересно, и у которых довольно неплохо получается, решать задачи бизнеса (если же быть точным, то задачи системы более высокого уровня), то есть играть во властные игры, в которых нет правил.
Для подавляющего же большинства людей проблемы власти не интересны, а скорее всего просто страшат, и потому они не могут и не хотят ими заниматься. Для таких людей гораздо комфортнее выступать в роли исполнителей с четкими и понятными правилами игры.
Беда наступает тогда, когда в команде программистов не оказывается игрока во власть. И тогда эта команда превращается в пушечное мясо, которое бизнес использует в своих личных целях, не гнушаясь при этом никакими методами. Ведь кто бы что ни говорил, но наш мир стоит на праве сильного, а все остальные ценности — лишь звенья в пищевой цепочке.
Проблема в том, что потребность во власти ощущают не более 5-7 (максимум 10) процентов от общего числа людей. Поэтому среди любых специальностей, в том числе среди программистов, встречаются люди, которым интересно, и у которых довольно неплохо получается, решать задачи бизнеса (если же быть точным, то задачи системы более высокого уровня), то есть играть во властные игры, в которых нет правил.
Для подавляющего же большинства людей проблемы власти не интересны, а скорее всего просто страшат, и потому они не могут и не хотят ими заниматься. Для таких людей гораздо комфортнее выступать в роли исполнителей с четкими и понятными правилами игры.
Беда наступает тогда, когда в команде программистов не оказывается игрока во власть. И тогда эта команда превращается в пушечное мясо, которое бизнес использует в своих личных целях, не гнушаясь при этом никакими методами. Ведь кто бы что ни говорил, но наш мир стоит на праве сильного, а все остальные ценности — лишь звенья в пищевой цепочке.
Беда наступает тогда, когда в команде программистов не оказывается игрока во власть.
А если оказывается? Зачем ему отстаивать интересы команды? Такие люди себя ощущают некомфортно при написании кода, и стремятся перейти на новый уровень. Если ради этого надо загнать коллег или подчиненных, то почему бы и нет?
Если ради этого надо загнать коллег или подчиненных, то почему бы и нет?Потому что на новом уровне человека без команды просто «сожрут». Те у кого команда будет. Так что человек, умеющий в игру во власть будет-таки поддерживать команду… но в первую очередь, конечно, себя. Тут ничего не поделаешь.
Все просто — без команды нет власти. Если Вас интересуют подробности, то рекомендую ознакомиться с книгой Никколо Макиавелли «Государь» (1513 год). В процессе чтения этой книги только нужно вместо слова «государь» подставлять «руководитель», а вместо слова «народ» — «коллектив».
Думаю, что есть разные люди, а не только "такие" и "не такие". В том числе, есть люди, которые стремятся перейти на новый уровень чтобы самим себе писать ТЗ, по которым им будет комфортно писать код. Или вообще не писать ТЗ. Ещё вариант: выйти на новый уровень, чтобы брать себе самые интересные задачи, а команде давать рутину (причём для команды это могут быть интересные задачи, — интересы у разных людей разные). Ещё: просто стремление понимать, что и зачем ты делаешь. Можно много мотивов предположить из-за которых люди стремятся выйти на новый уровень, а не находиться на уровне где задачи приходят в виде чёткой спецификации, которую нужно просто имплементировать. При этом сознательно себя ограничивают тем уровнем, где ещё можно писать код.
У нас был сотрудник который очень хорошо умел «во власть» и было видно как ему некомфортна регулярная научная работа. Т.е. возможно он была бы хорошим менеджером, но таких должностей у нас нет, а должность завлаба ему не светила. В результате он поругался почти со всеми с кем мог, ушел на работу в некую IT-контору на регулярную должность, там ситуация повторилась, сейчас сотрудник в зарубежной конторе и всё идет к увольнению. Увы — менеджер-начальник без своей команды никому не нужен.
А как думаете, в кровавом энтерпрайзе он смог бы найти себе место, чтобы ставить задачи и контролировать их выполнение, а пипл менеджат пусть специально обученные люди? Или не смог бы смирится с рамками и рутиной, в которую там загоняют менеджеров?
У вас есть вакансия? )) Если соберется возвращаться — могу вам прислать, скажете мне спасибо или нет — не знаю.
На новом заграничном рабочем месте тоже зреет конфликт — начальник сотрудника слегка присваивает себе его достижения (по его словам) — для KPI. Это кстати кусочек пресловутого «умения во власть» — что человек видит это. С мозгами там всё очень хорошо. ИМХО таким людям надо свою контору организовывать, чтобы не было начальников вообще.
На новом заграничном рабочем месте тоже зреет конфликт — начальник сотрудника слегка присваивает себе его достижения (по его словам) — для KPI. Это кстати кусочек пресловутого «умения во власть» — что человек видит это. С мозгами там всё очень хорошо. ИМХО таким людям надо свою контору организовывать, чтобы не было начальников вообще.
ИМХО таким людям надо свою контору организовывать, чтобы не было начальников вообще
Как? Думаете вот так сходу это реально?
Ну… у меня был знакомый — с детства спекулировал алкоголем и чем придется. Работал в каких-то конторах по найму — но быстро начинал там работать на себя с предсказуемым результатом. Потом организовал свою контору ну и лет 15 себя хорошо чувствовал. Потом рынок его деятельности схлопнулся, он пошел куда-то работать — хватило его месяца на три. Это я к чему — кто-то же организует какие-то конторы.
За эти 15 лет он так и был малым бизнесом? Или выстроил что-то большое и оно рухнуло?
Малым, но с вполне так хорошей прибылью — товарищ купил несколько квартир и несколько хороших авто.
Я к тому, что если нет цели и понимания, как построить что-то большое, где, как сейчас модно говорить «можно выйти из операционки», то бизнес ли это? Или просто выполнение работы 1-3 наемных сотрудников с положением в карман всей маржи? Ну а прибыль размером в несколько квартир и машин за пятнадцать лет делает и линейный персонал с 0 подчиненных в технологических компаниях.
«можно выйти из операционки» А что это значит?
Скорее второе — ну не 1-3 сотрудника, а скорее 10.
Сейчас попробую залезть в чужой карман и посчитать. )
Три квартиры + две машины это где-то 25 млн. Это всё уже давно, т.е. было куплено лет за 7-8. Это соответствует личной среднемесячной ЗП в 300т+на веселое житье и частую покупку дорогих шмоток. Т.е. по нынешним меркам это около 500 тыс.
Думается не так много линейных сотрудников получающих такие ЗП.
Скорее второе — ну не 1-3 сотрудника, а скорее 10.
Сейчас попробую залезть в чужой карман и посчитать. )
Три квартиры + две машины это где-то 25 млн. Это всё уже давно, т.е. было куплено лет за 7-8. Это соответствует личной среднемесячной ЗП в 300т+на веселое житье и частую покупку дорогих шмоток. Т.е. по нынешним меркам это около 500 тыс.
Думается не так много линейных сотрудников получающих такие ЗП.
Под фразой подразумевают, что основатель не принимает решений о текущей работе бизнеса. И если он исчезнет, то бизнес будет работать без него как минимум до серьёзных изменений рынка и общества. Условно, кому продавать, с кем заключить контракт, какую выставить цену, кого из не топов взять на работу/уволить/повысить, — все это решается без основателя. А основатель вмешивается только серьёзных измений в процессе, работающем без него. При хедкаунте в 10 человек это почти невозможно.
Ну а касательно зп, да, 500 это выше линейного персонала. Где-то $5к, думаю, потолок.
А! Ну да. Если конторой в 10 человек не заниматься, то либо она утонет либо перейдет к шустрому менеджеру. Типично когда кто-нибудь из сотрудников организует свою аналогичную контору и уводит половину сотрудников.
Типично когда кто-нибудь из сотрудников организует свою аналогичную контору и уводит половину сотрудников.
Да, мерзость. Хуже только, когда крысы остаются у тебя на зп, но контора начинает работать на них. Лиды сливают на сторону или создают фирму-прокладку, и с ней заключают контракты по нерыночно низким ценам, а она уже с реальным клиентом по рыночной.
Ну как мерзость… джунгли капитализма. Изучение рынка возможно только в бою, желательно за чужой счет. Я не уверен, что тут вообще применимы этические категории, хотя разумеется эмоциональная составляющая не исключается. )
Видел как-то текст как правильно покупать-продавать свою квартиру. Начиналось с того, что надо взять на работе отпуск и устроиться агентом в агенство недвижимости, пару месяцев поизучать рынок, получить доступ к базам и дальше грамотно продавать-покупать свою квартиру. Предполагалось, что на этом можно получить плюс несколько сотен тыс. руб.
Видел как-то текст как правильно покупать-продавать свою квартиру. Начиналось с того, что надо взять на работе отпуск и устроиться агентом в агенство недвижимости, пару месяцев поизучать рынок, получить доступ к базам и дальше грамотно продавать-покупать свою квартиру. Предполагалось, что на этом можно получить плюс несколько сотен тыс. руб.
вы правы, в любом бизнесе есть норма прибыльности. В таких сферах как недвижимость, где цена — это продукт торговли и переговоров и цена высокая, маржа тоже высокая.
Можно спокойно сидеть на попе и заплатить эту маржу бизнесу и получить услугу, а можно побегать, пошустрить по базам и забрать эту маржу себе
Можно спокойно сидеть на попе и заплатить эту маржу бизнесу и получить услугу, а можно побегать, пошустрить по базам и забрать эту маржу себе
Ну вы это — поаккуратней. Это бизнес иногда читает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как делать карьеру программисту, не решая задачи бизнеса