пост-знакомство
для всех в будущем прибывших: меня зовут Павел, я основатель агентства по разработке ПО SAKHAROV GROUP.
одной ногой в найме, DevLead в банке синего цвета, пилю код по всем канонам корпораций.
пишу о том, как строю с нуля свое агентство, периодически рассуждаю об актуальном и совсем немного морализаторствую (по выходным).
здесь можно найти посты:
- об альтернативных структурах в управлении компанией;
- о проблемах российского айти;
- о том, как идут дела с агентством;
- и вообще о всяком разном про жизнь, it и деньги.
stay tuned.
для всех в будущем прибывших: меня зовут Павел, я основатель агентства по разработке ПО SAKHAROV GROUP.
одной ногой в найме, DevLead в банке синего цвета, пилю код по всем канонам корпораций.
пишу о том, как строю с нуля свое агентство, периодически рассуждаю об актуальном и совсем немного морализаторствую (по выходным).
здесь можно найти посты:
- об альтернативных структурах в управлении компанией;
- о проблемах российского айти;
- о том, как идут дела с агентством;
- и вообще о всяком разном про жизнь, it и деньги.
stay tuned.
Telegram
сахаровские чтения
холакратия
еще про управление и структуры.
классическая иерархия начальник -> начальник (поменбше) -> линейный сотрудник является только одним из методов организации работы в компании. более прогрессивные подходы обычно первым делом появляются в разработке…
еще про управление и структуры.
классическая иерархия начальник -> начальник (поменбше) -> линейный сотрудник является только одним из методов организации работы в компании. более прогрессивные подходы обычно первым делом появляются в разработке…
сахаровские чтения pinned «пост-знакомство для всех в будущем прибывших: меня зовут Павел, я основатель агентства по разработке ПО SAKHAROV GROUP. одной ногой в найме, DevLead в банке синего цвета, пилю код по всем канонам корпораций. пишу о том, как строю с нуля свое агентство…»
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Анна Караулова
Please open Telegram to view this post
VIEW IN TELEGRAM
о рентабельности
итак, имеем: senior разработчик получает ~300к в месяц, аутстафф/аутсорсинг продает его по 3к/час == 480к в месяц. с учетом налогов конторе он обойдется ~в 400к, + аренда офиса, + софт, + непроизводственный персонал. и тогда рентабельность выходит…
60-70%.
как же так? да легко, сеньор разработчик, которого вам впаривают - далеко не сеньор. часы в сводных таблицах - вероятно х2 или х3.
те, кто успел побывать в EPAM и иных галерах знают, как это работает. реально в 80% случаев миддла поднатаскают на собесы и впарят вам как сеньора. в агентской сфере все еще хуже, так как зарплаты в студиях ниже рыночных (видел Middle-разработчика за 140000, как вам?) и за сеньора могут выдать Junior+.
вряд ли кому-то я открываю глаза, и тем не менее, навеян данный пост вот чем: поговорили с человеком, хотел разработать под себя аналитическую систему, я назвал ценник от 2,5кк, и вышло что мой минимум - больше чем их максимум.
откуда цены:
- 2х Senior по 300к с коэффициентом 1,5 (учесть налоги, софт, и т.д.)
- 2х Junior по 80к с коэффициентом 1,5 (красить кнопки)
два месяца работы и вуаля - 2,280,000. плюс хоть какая-то маржа себе.
оплату по часам, кстати, на проектах где заказчик приходит за разработкой под ключ (читай «даже без ТЗ») я считаю максимальным тупизмом. нереально (или по крайней мере очень сложно) оценить время и ресурсы на проект, если он идет больше трех-четырех месяцев, не заложив х2/х3 риски (если вы так умеете - будете первые во всех рейтингах рунета). T&M - не серебряная пуля, скорее всего простозаебете клиента апсейлом часов.
p.s.: а вообще это все было для непосвященных и тех, кому интересно, как сайт может стоить несколько миллионов.
итак, имеем: senior разработчик получает ~300к в месяц, аутстафф/аутсорсинг продает его по 3к/час == 480к в месяц. с учетом налогов конторе он обойдется ~в 400к, + аренда офиса, + софт, + непроизводственный персонал. и тогда рентабельность выходит…
60-70%.
как же так? да легко, сеньор разработчик, которого вам впаривают - далеко не сеньор. часы в сводных таблицах - вероятно х2 или х3.
те, кто успел побывать в EPAM и иных галерах знают, как это работает. реально в 80% случаев миддла поднатаскают на собесы и впарят вам как сеньора. в агентской сфере все еще хуже, так как зарплаты в студиях ниже рыночных (видел Middle-разработчика за 140000, как вам?) и за сеньора могут выдать Junior+.
вряд ли кому-то я открываю глаза, и тем не менее, навеян данный пост вот чем: поговорили с человеком, хотел разработать под себя аналитическую систему, я назвал ценник от 2,5кк, и вышло что мой минимум - больше чем их максимум.
откуда цены:
- 2х Senior по 300к с коэффициентом 1,5 (учесть налоги, софт, и т.д.)
- 2х Junior по 80к с коэффициентом 1,5 (красить кнопки)
два месяца работы и вуаля - 2,280,000. плюс хоть какая-то маржа себе.
оплату по часам, кстати, на проектах где заказчик приходит за разработкой под ключ (читай «даже без ТЗ») я считаю максимальным тупизмом. нереально (или по крайней мере очень сложно) оценить время и ресурсы на проект, если он идет больше трех-четырех месяцев, не заложив х2/х3 риски (если вы так умеете - будете первые во всех рейтингах рунета). T&M - не серебряная пуля, скорее всего просто
p.s.: а вообще это все было для непосвященных и тех, кому интересно, как сайт может стоить несколько миллионов.
о рисках (как бы о рентабельности часть 2)
есть такой стандарт, PMBoK, который говорит, что на этапе первой оценки проекта ошибка составляет от 25% в меньшую сторону до 75% в большую. то есть первый раз прикидываясколько займет эта таска время на проект, статистически вы преуменьшите вдвое.
есть еще обзор от Standish Group где сказано, что 44% проектов срывают сроки и занимают 222%(!!!) изначально заложенного времени и 189% ресурсов (опять ошибка примерно х2).
все это свойственно для нашего любимого вотерфолла и его ответвлений (таких как agile в РФ например, хаха), что кстати позволяет отличить карго-культ-agile от тру-agile: если вы знаете, что будете делать в спринте «С+12» - у вас agile не планируется (уловили каламбур?).
есть метод «критической цепи» (кстати подсказали мне его в комментариях, спасибо), решает проблему сорванных сроков онкак ни странно уменьшением сроков! все ваши заложенные риски (а они статистически х2) вы выкидываете для команды, но оставляете для заказчика/стейкхолдера. освобожденное время у вас оказывается в конце и называется «буфер проекта», работает это из принципа «работа занимает все отведенное на нее время», а еще там все немного сложнее и вот тут можно почитать. главное команде о сроках не говорить)
вообще странно пытаться работать по scrum/agile, если вам нужны четкие сроки. суть этих идей лежит в быстрой реакции на внешние факторы, а если вы можете сказать, что будет через два года - вам вот эти все дейли/ретро/груминги зачем?
p.s.: но в нашем шатком современном мире я все еще придерживаюсь мнения, что переход к гибкому управлению не столько модная фишка, сколько необходимость, просто применять надо с головой.
есть такой стандарт, PMBoK, который говорит, что на этапе первой оценки проекта ошибка составляет от 25% в меньшую сторону до 75% в большую. то есть первый раз прикидывая
есть еще обзор от Standish Group где сказано, что 44% проектов срывают сроки и занимают 222%(!!!) изначально заложенного времени и 189% ресурсов (опять ошибка примерно х2).
все это свойственно для нашего любимого вотерфолла и его ответвлений (таких как agile в РФ например, хаха), что кстати позволяет отличить карго-культ-agile от тру-agile: если вы знаете, что будете делать в спринте «С+12» - у вас agile не планируется (уловили каламбур?).
есть метод «критической цепи» (кстати подсказали мне его в комментариях, спасибо), решает проблему сорванных сроков он
вообще странно пытаться работать по scrum/agile, если вам нужны четкие сроки. суть этих идей лежит в быстрой реакции на внешние факторы, а если вы можете сказать, что будет через два года - вам вот эти все дейли/ретро/груминги зачем?
p.s.: но в нашем шатком современном мире я все еще придерживаюсь мнения, что переход к гибкому управлению не столько модная фишка, сколько необходимость, просто применять надо с головой.
где учить(-ся) на разработчика
в современной РФии существует дихотомия между ВУЗовским образованием и онлайн-курсами, и каждый из упомянутых обладает своими недостатками. и после универа специалистгавно некомпетентен, и после курсов, так откуда все таки берутся нормальные разработчики?
большинство еще и просекли, что к собесам можно готовиться (как и ваш покорный), что еще больше усложняет ситуацию с поиском спецов. ведь подготовиться к собесам - это (увы) не подготовиться к работе, хоть и дает определенный буст.
ВУЗовские разработчики хорошо понимают 6 с половиной нормальных форм, но плохо понимают написание селектов. мощная теоретическая база usually разбивается о суровую реальность двух телефонов пользователя через запятую в одной ячейке таблицы, потому что прямо сейчас
«вайтишники» же идеальный Middle - на раз-два сделают контроллер, сервис, JPaREpOsItory и прочее, но не более. здесь гавнокод бьется о реальность обхода дерева в ширину, динамическое программирование, а иногда и МатАн + ЛинАл (эх, как бы хотелось иметь такие задачи в работе). проблема этих ребят ровно противоположная ВУЗовским, с практикой все более менее ок (если курсы хорошие), но теория - тихий ужас. есть шанс, что ваш разраб просто «выучил код».
и выучит еще, как читать с Кафки, как писать свой BeanPostProcessor и т.д., но вот решит ли он негуглящуюся задачу - это лотерея.
проблема пока не решена никем (по крайней мере эффективно), крупные компании открывают корпоративные школы, где «докручивают» ребят до нужного уровня, амыши поменбше агентства просто перебирают народ, в надежде найти талант. возможно менторство может с этим помочь, но опять же, это либо внутри компании, либо дорого, а мы тут с вами деньги зарабатываем вапщета ✌️
p.s.: в голове крутится пара идей, как бороться с зазубриванием собесов, но мысль пока еще формируется, stay tuned
в современной РФии существует дихотомия между ВУЗовским образованием и онлайн-курсами, и каждый из упомянутых обладает своими недостатками. и после универа специалист
большинство еще и просекли, что к собесам можно готовиться (как и ваш покорный), что еще больше усложняет ситуацию с поиском спецов. ведь подготовиться к собесам - это (увы) не подготовиться к работе, хоть и дает определенный буст.
ВУЗовские разработчики хорошо понимают 6 с половиной нормальных форм, но плохо понимают написание селектов. мощная теоретическая база usually разбивается о суровую реальность двух телефонов пользователя через запятую в одной ячейке таблицы, потому что прямо сейчас
так нада
. + по какой-то причине имеют абсолютно безумное ЧСВ и откровенно детское отношение к жизни первые пару лет работы.«вайтишники» же идеальный Middle - на раз-два сделают контроллер, сервис, JPaREpOsItory и прочее, но не более. здесь гавнокод бьется о реальность обхода дерева в ширину, динамическое программирование, а иногда и МатАн + ЛинАл (эх, как бы хотелось иметь такие задачи в работе). проблема этих ребят ровно противоположная ВУЗовским, с практикой все более менее ок (если курсы хорошие), но теория - тихий ужас. есть шанс, что ваш разраб просто «выучил код».
и выучит еще, как читать с Кафки, как писать свой BeanPostProcessor и т.д., но вот решит ли он негуглящуюся задачу - это лотерея.
проблема пока не решена никем (по крайней мере эффективно), крупные компании открывают корпоративные школы, где «докручивают» ребят до нужного уровня, а
p.s.: в голове крутится пара идей, как бороться с зазубриванием собесов, но мысль пока еще формируется, stay tuned
Please open Telegram to view this post
VIEW IN TELEGRAM
ИИ vs качество
только мне начинает казаться, что очередная ГПТ смогла выдать нечто стоящее, как все надежды на то, что ИИ заберет мою работу разбиваются о жестокую реальность.
попробовали заюзать одну нейросетку, которая обещала сделать нам сайт на React (чем черт не шутит, представляете экономию?) - результат не оправдал ни одного из ожиданий.
- визуально приемлемо (даже хорошо, вполне соблюла дизайн-макет);
- попыталась в компоненты.
- в компоненты не получилось;
- очень сложный код, там где не надо, очень простой где надо.
проблемы нейросетей как будто никуда не делись за несколько лет. все еще бедыс башкой со структурой, все еще качество уменьшается экспоненциально вместе с ростом объема работ, все еще ходят по кругу при возникновении проблем с задачей.
кстати, нашумевший Devin.AI оказался нехорошей компанией, навравшей на демо. так что все еще клепать ДТОхи самому, все еще.
в плане нейросетей я скорее анти-ИИ-евангелист, потому что еще ни разу не видел ничего, кроме игрушки на вечерок. есть всякие стартапы с вау-эффектом (типа «цифровых двойников»), но абсолютно все они, всегда, идут с пометкой «ну да, заметно, что ИИ, но это пока».
возможно это проблема «китайской комнаты», но я лично считаю что текущий подход слаб архитектурно. пытаться растить до безумия число параметров в ГПТ это примерно как в тупую растить объем мотора: в итоге получится 7-литровый двигатель на 112 сил(минутка автоистории).
p.s.: вышел из спячки после длинных выходных.
только мне начинает казаться, что очередная ГПТ смогла выдать нечто стоящее, как все надежды на то, что ИИ заберет мою работу разбиваются о жестокую реальность.
попробовали заюзать одну нейросетку, которая обещала сделать нам сайт на React (чем черт не шутит, представляете экономию?) - результат не оправдал ни одного из ожиданий.
из плюсов:
- визуально приемлемо (даже хорошо, вполне соблюла дизайн-макет);
- попыталась в компоненты.
из минусов:
- в компоненты не получилось;
- очень сложный код, там где не надо, очень простой где надо.
проблемы нейросетей как будто никуда не делись за несколько лет. все еще беды
кстати, нашумевший Devin.AI оказался нехорошей компанией, навравшей на демо. так что все еще клепать ДТОхи самому, все еще.
в плане нейросетей я скорее анти-ИИ-евангелист, потому что еще ни разу не видел ничего, кроме игрушки на вечерок. есть всякие стартапы с вау-эффектом (типа «цифровых двойников»), но абсолютно все они, всегда, идут с пометкой «ну да, заметно, что ИИ, но это пока».
возможно это проблема «китайской комнаты», но я лично считаю что текущий подход слаб архитектурно. пытаться растить до безумия число параметров в ГПТ это примерно как в тупую растить объем мотора: в итоге получится 7-литровый двигатель на 112 сил
p.s.: вышел из спячки после длинных выходных.
Zeniteq
Devin's Demo As The "First AI Software Engineer" Was Faked
Were you one of those who got fooled by Devin's demo video?
у нас есть печеньки
откопал у одного человечка в блоге оправдание использования «темных паттернов» в продукте. что это такое и с чем его едят:
темные паттеры (dark patterns) - относительно серые схемки на тему взаимодействия с пользователем. наше любимое «пользовательское соглашение», где мелким шрифтом пишутчто твоя жопа теперь собственность майкрософт что ваши данные будут нагло впарены третьим лицам - один из них.
а вот еще:
- вопросы с подвохом на чекбоксах;
- добавление в корзину товара без согласия пользователя;
- отвлечение внимания (например большой кнопкой «купить» от маленькой «отказаться от рассылки»);
- подмена действия (интуитивно UX-элемент должен делать одно, а реально делает другое);
- скрытые платежи;
- и другое.
человек, который придумал эту классификацию, зовется Бригналл и по ссылке статья в вики по этой теме.
естественно, если вы работаете не на РетЕншН, а на объемы продаж, и бюджет на маркетинг у вас 50% от оборота - то схема рабочая. некоторыми пунктами из списка не гнушаются даже самые крупные представители бизнеса (привет любому Банку и их кабале с отменой страховки когда берешь кредит).
мое мнение -пидорство в чистом виде, говорит только о том, что «продукт то ваш, гавно!». если вы считаете, что в целом это норм - фу, отпишитесь (или не подписывайтесь).
p.s.: человек, о котором говорилось в начале, оправдывал эту срань тем, «что рынок такой сейчас», и вообще, если не юзаете такую дрянь - то вы не профессионал. как по мне, все ровно наоборот, профессионал в состоянии делать продукт без наебалова, а если ВОТ ЭТО ваши авторские методы продвижения продукта - вы бездарь и не очень хороший человек.
откопал у одного человечка в блоге оправдание использования «темных паттернов» в продукте. что это такое и с чем его едят:
темные паттеры (dark patterns) - относительно серые схемки на тему взаимодействия с пользователем. наше любимое «пользовательское соглашение», где мелким шрифтом пишут
а вот еще:
- вопросы с подвохом на чекбоксах;
- добавление в корзину товара без согласия пользователя;
- отвлечение внимания (например большой кнопкой «купить» от маленькой «отказаться от рассылки»);
- подмена действия (интуитивно UX-элемент должен делать одно, а реально делает другое);
- скрытые платежи;
- и другое.
человек, который придумал эту классификацию, зовется Бригналл и по ссылке статья в вики по этой теме.
естественно, если вы работаете не на РетЕншН, а на объемы продаж, и бюджет на маркетинг у вас 50% от оборота - то схема рабочая. некоторыми пунктами из списка не гнушаются даже самые крупные представители бизнеса (привет любому Банку и их кабале с отменой страховки когда берешь кредит).
мое мнение -
p.s.: человек, о котором говорилось в начале, оправдывал эту срань тем, «что рынок такой сейчас», и вообще, если не юзаете такую дрянь - то вы не профессионал. как по мне, все ровно наоборот, профессионал в состоянии делать продукт без наебалова, а если ВОТ ЭТО ваши авторские методы продвижения продукта - вы бездарь и не очень хороший человек.
Wikipedia
Тёмные паттерны
Тёмные паттерны — приёмы, как правило относящиеся к проектированию пользовательских интерфейсов, которые используются в попытке склонить пользователя к действиям, которые он считает нежелательными. Как пример — покупка ненужной дополнительной услуги или подписка…
Please open Telegram to view this post
VIEW IN TELEGRAM
вы думали я сдох?
а я не сдох, я думал.
всем добрый вечер.
p.s.: я в курсе, что тут 20 человек, просто привыкаю быть знаменитостью.
а я не сдох, я думал.
всем добрый вечер.
p.s.: я в курсе, что тут 20 человек, просто привыкаю быть знаменитостью.