Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Хочу поделиться чеклистом с советами от Skyeng о том, как кратно ускорить разработку. Как считаете, для кого применим такой подход, а для кого нет?
Осталось только найти фуллстека, максимально автономного, принимающего на себя риски, очень-очень сильного, согласного работать более
А там нет чеклиста, как девять беременных женщин могут родить за один месяц?
Из того, что я собрал по отдельным окошкам (очевидно просто написать тезисы было не модно).
— Работа 50 часов в неделю.
— Каждый девелопер делает фронт, бэк + девопс. Тестит очевидно то же сам.
— Модули автономные, но если девелоперу что-то нужно в чужом модуле то он должен сам в него вникнуть и починить.
— Вместо закладываться на будущее мы педалим быстро и потом быстро разгребаем последствия наших быстрых решений.
Как считаете, для кого применим такой подход, а для кого нет?
ИМХО, применим для небольших, «одноразовых» проектов на заказ: быстро налабали — быстро спихнули, быстро получили профит.
На долгосрочном проекте вылезут проблемы такого подхода:
— Что бы набирать только самых классных и «универсалов» на 50 часов — им нужно платить хорошо выше рынка. Что делать если временно работы на всех не хватает? Выгонять и потом опять искать?
— Люди не могут постоянно напряженно работать по 50 часов. Через Х недель производительность начнет падать или упадет качество.
— Специалист во всем — специалист ни в чем. Очень часто вместо лучших решений от «универсалов» будем получать быстрые, но не слишком удачные. А экспертов нет — некому подсказать.
— Следствие быстрых решений — технический долг. Он имеет тенденцию накапливаться незаметно. Но в какой-то момент вылезет — и окажется что быстрого решения уже нет. Так умирал ни один проект.
Как это работало по моему опыту:
В период спада спроса на «попачасы» компания решилась брать фиксед прайс проекты.
Собрали «команду мечты» из синьоров: отдельно фронт, бэк, мобаил, QA, DBA + девопс и толковый менеджер. Девелоперам платили ставку + солидную премию если успели сделать и сдать проект в срок и без багов. Поэтому у команды был интерес делать хорошо и овертаймить если надо.
Проекты брали продолжительностью до полугода ± пару месяцев. Соответственно после успешной сдачи проекта часто была пауза (от недели до месяца), когда команда могла отдохнуть.
Команде такая схема работы нравилось: можно было хорошо заработать, и потом отдохнуть. Плюс моральное удовольствие от успешно сделанного проекта.
Но для компании такая модель была очевидно менее выгодная, чем продавать «попачасы», поэтому как только набрали унылых сапортных проектов — «команду мечты» разогнали.
Военная часть... Курилка. Сидят 4 лейтенанта. Один предлагает идти к командиру части проситься в отпуск. Встали пошли. Заходит к командиру первый:
— Товарищи полковник, лейтенант Пупкин. Разрешите в отпуск.
— Да ты че! В отпуск, говоришь? Давай рацпредложение рационализаторское предложение) — пойдешь в отпуск!
— Легко! Вон у Вас под окном солдат траву косит. Че он косой в одну сторону машет? Давайте ему вторую косу привяжем, пусть косит налево и направо!
— Молодец! В отпуск!
Заходит второй:
— Давай рацпредложение...
— Легко! Вон у Вас под окном солдат траву косит. Че он косой туда-сюда машет? Давайте ему к косе привяжем вилы, пусть сразу в кучки складывает!
— Молодец! В отпуск!
Заходит третий:
...
— Давай рацпредложение...
— Легко! Вон у Вас под окном солдат траву косит. Че он косой туда-сюда машет, траву в кучки складывает? Давайте к нему привяжем тележку, пусть сразу и отвозит!
— Молодец! В отпуск!
Заходит четвертый:
...
— Давай рацпредложение...
— Не знаю.
— Ну-у-у-у... Так иди думай. Придумаешь приходи!
Выходит лейтенант на крыльцо, закуривает нервно, стоит «репу морщит».
И тут подходит к нему этот солдат. С этой хреновиной в руках с привязанной тележкой, весь потный, обессиленный. И злобно так, спрашивает у лейтенанта:
— Чё, товарищ лейтенант, в отпуск хотите?!
— Да-а...
— Б...ь, рацпредложение не можете придумать?!
— Да-а...
— Б...ь, ФАРУ МНЕ НА ЛОБ!!! ФАРУ!!! ЧТОБЫ НОЧЬЮ КОСИЛ!!!
Непрерывно ищем более сильных и классных
Всё правильно- надо чтобы только альфачи работали на проекте. Сильные- так чтобы 100 жал за раз отпола не краснея. Классный- ну вообще классный.
Прощаемся со слабыми
Что то вспомнилось: вы самое слабое звено © — голосом ведущей.
Вовлекаем в работу более 40 часов в неделю
Вот это понимаю ноуХау. Съездите в европу на саммит менеджеров- раскажите германцам, нервейцам, денмаркцам и другим лидерам тратап культур в европе- что их идеи о км/ч засов в неделю
Движение в сторону фул-стэков
Вот это ясщитаю правильная мысль. И вообще 2019 год объявили годом javascript.
А то напридумывали там каких то законом Мура. Производительность железа растет, память дешевая. Даёшь блокнот по заметок съдающий 2 гига памяти с подгрузкой всего из интернета. И конечно же надо переплюнуть биткойн мейнеры по загрузке процессора — на каждый чих в приложении. Всё будет жаваскрипт
Мы не боимся ошибиться. не надо бояться уронить продакшн, но надо позаботиться, чтобы в
Вот всё жду когда ваши адепты начнут разрабатывать автопилоты машин
Тогда всем вокруг прийдется
учиться двигаться быстро
чтобы такие домой добраться живым.
Потому что система автопилота разрабатывалась с мыслью что:
случае его падения была затронута небольшая часть пользователей
Подумамешь — кого то задавит- ну так всёравно перенаселение в африке.
Ну и конечно, я больше не удивляюсь таким темам как «пропал swift платеж» и тд
Мы умеем бороться с последствиями
В авральном режиме в 2 часа ночи по 3G каналу конектится в проду на другом материке- только для того чтобы обнаружить что логи то некто не пишет- ибо нет времени на это =)
Это так «чудесно», что возникает вопрос а не троллинг ли это?
Каждый может разработать и бэкенд и фронтенд
Разработчики выполняют роль девопсов
Как бы по такой схеме работают ноунейм конторы, которым банально не хватает денег на специалистов или организованности для распределения обязанностей. Только они не додумались выставлять этот бардак неким ноу хау.
Или это как в шутке?
Каждый наш сотрудник — профессионал-многостаночник, энтузиаст своего дела, самоотверженно готовый броситься решать любое количество проблем, находящихся в зоне его досягаемости, независимо от его компетенции!©
отсюда yasdelie.ru
Военная часть... Курилка. Сидят 4 лейтенанта. Один предлагает идти к командиру части проситься в отпуск. Встали пошли. Заходит к командиру первый:
— Товарищи полковник, лейтенант Пупкин. Разрешите в отпуск.
— Да ты че! В отпуск, говоришь? Давай рацпредложение рационализаторское предложение) — пойдешь в отпуск!
— Легко! Вон у Вас под окном солдат траву косит. Че он косой в одну сторону машет? Давайте ему вторую косу привяжем, пусть косит налево и направо!
— Молодец! В отпуск!
Заходит второй:
— Давай рацпредложение...
— Легко! Вон у Вас под окном солдат траву косит. Че он косой туда-сюда машет? Давайте ему к косе привяжем вилы, пусть сразу в кучки складывает!
— Молодец! В отпуск!
Заходит третий:
...
— Давай рацпредложение...
— Легко! Вон у Вас под окном солдат траву косит. Че он косой туда-сюда машет, траву в кучки складывает? Давайте к нему привяжем тележку, пусть сразу и отвозит!
— Молодец! В отпуск!
Заходит четвертый:
...
— Давай рацпредложение...
— Не знаю.
— Ну-у-у-у... Так иди думай. Придумаешь приходи!
Выходит лейтенант на крыльцо, закуривает нервно, стоит «репу морщит».
И тут подходит к нему этот солдат. С этой хреновиной в руках с привязанной тележкой, весь потный, обессиленный. И злобно так, спрашивает у лейтенанта:
— Чё, товарищ лейтенант, в отпуск хотите?!
— Да-а...
— Б...ь, рацпредложение не можете придумать?!
— Да-а...
— Б...ь, ФАРУ МНЕ НА ЛОБ!!! ФАРУ!!! ЧТОБЫ НОЧЬЮ КОСИЛ!!!
Выскажу свои мысли по этому поводу, со стороны ТехЛида команды Oracle разработчиков, вовлеченных в разработку множества Legacy-приложений компании.
1.1. «Непрерывно ищем более сильных и классных».
Сразу вспоминается тезис: «Пишу быстро, качественно, недорого. Выберите любые два пункта». Насколько я понимаю, приоритет к аттрибутам «Быстро» и «Качественно».
И мы сходу получаем «Дорого».
1.2. «Прощаемся со слабыми».
То есть, после выполнения пункта 1, вы прощаетесь с одним из разработчиков, нанятых на прошлом этапе.
Если учесть, что «слабый» разработчик тоже нанимался по тезисам п.1, то он априори является «Дорогим» для компании, уже имеющим опыт разработки именно под ваши требования.
Получается, что вы меняете более дорогого, но уже опытного относительно нюансов компании разработчика на менее дорогого, но более перспективного.
А если ожидания не оправдаются, то на время, пока компания ищет разработчика по требованиям п.1.1, оставшимся достается кусок работы уже уволенного, что явно не добавит им хорошего настроения.
1.3. «Вовлекаем в разработку более 40 часов в неделю».
Ок, но необходимо учитывать, что НЕ КАЖДЫЙ разработчик, нанятый в п.1.1, будет готов к такому режиму работы.
Скажу больше, профессиональный разработчик практически всегда негативно относится к переработкам, даже оплачиваемым по ставке xN.
А исходя из моего опыта, внеурочка для разработчика (исключая форс-мажоры) является прямым следствием недоработки других участников проекта.
Забегая вперед, в Вашем случае переработки будут ВСЕГДА, и это является прямым сигналом того, что на разработчика навесили кучу обязанностей, с которыми он справляется плохо.
То есть, тут надо «не кровати переставлять, а девочек менять» ©.
2.1. Каждый может разработать и бэкенд, и фронтенд.
2.3. Есть дизайн-система
3.2. Отсутствие взаимозависимости между командами
3.3. Отсутствие зависимостей от внешних обстоятельств
Сам имея опыт фуллстек-разработчика, который впоследствии стал узкоспециализированным, могу согласиться.
Но если возвращаться к п.1.1, то быстрее и качественнее будет разработка каждой из частей конкретным специалистом,
ПРИ УСЛОВИИ обеспечения между ними нормальной рабочей коммуникации.
Если с коммуникацией проблемы — то фиксить нужно именно эту проблему.
Вы же предлагаете искать специалистов, которым не нужно между собой коммуницировать.
То есть, просто заметая проблему под ковер. Ок, тоже подход.
2.2. Разработчики выполняют роль девопсов.
2.4. Разработчики — как маленькие продакты.
То есть, Вы на одном человеке замыкаете весь жизненный цикл приложения: он является Менеджером, Девелопером, Администратором.
Смелое, очень смелое решение.
Но краеугольный камень безопасности: девелопер никогда, ни при каких обстоятельствах не должен иметь доступ к продуктовой среде, на которой крутится разработанный им код.
В который, к тому же, он может внедрить любое решение, аргументируя это выданными ему обязанностями менеджера проекта.
Если Вы ПОКА не понимаете всю опасность данной ситуации, то просто поверьте на слово. Рано или поздно выстрелит так, что мало не покажется никому.
К тому же, прохождение аудита такого продукта становится попросту невозможным.
То есть, мы однозначно приходим к выводу, что такой подход имеет право на жизнь на мелких, достаточно некритичных к потери данным продуктам.
3.1. Автономность в коде.
3.4. Отсутствие зависимости от принятия решений.
Судя по Вашему же описанию, наличие Архитектора прямо конфликтует с п.2.1 и п.2.3.
Не понятна его роль в продукте. Каждый девелопер ведь «лучший из лучших», и из вашего описания прямо выходит, что сам девелопер является Архитектором.
И в п.3.4 Вы это явно указываете: девелопер просто обязан принимать решения самостоятельно, не ориентируясь на мнение других членов команды (я так понимаю, и заказчика тоже).
4.1. Мы не боимся ошибиться.
Нельзя не согласиться. Здравый и достаточно разумный подход в условиях высокой конкуренции.
При наличии культуры разработки в компании. И я так понял, определение того где можно рискнуть, а где нет — тоже предоставляется девелоперу?
То есть ваш девелопер еще выполняет роль и Риск-менеджера, и подразумевается, что он это тоже должен делать «быстро и качественно».
4.2. Мы минимизируем объем взрыва.
4.3. Мы умеем бороться с последствиями.
Я честно не понял, как у вас на этапе разработки закладываются на возможные проблемы и вырабатывают способы их минимизации.
То есть, при разработке четко видят, что это костыль, и вместо того, чтобы его сделать правильно, вырабатывают способы починки в ситуации, когда костыль сломается?
Оригинальный подход.
Резюме:
Плюсы: девелопер в вашей компании действительно будет быстро расти, т.к. будет совмещать в себе все возможные роли в проекте.
Это школа, и школа отличная.
Минусы: такая компания однозначно не является дрим-тим, и при получении определенного количества опыта человек благополучно спрыгнет в узкую специализацию чего-то из того, с чем он имел дело у вас в проекте.
И заметьте, на бОльшие деньги и мЕньший объем работы (практически всегда).
И очень навряд ли к вам пойдет работать человек, действительно являющийся экспертом хотя бы в нескольких направлениях (а такие есть, и ценятся они на вес золота).
Спасибо за детально описанное мнение. В основном согласен. Еще раз напишу, компания Skyeng — не моя, поэтому ответов на поставленные вопросы у меня нет.
Стараемся вовлекать членов команды в работу около 50 часов в неделю
Чушь полная, не все могут даже 8 часов за день интенсивно без прерывно писать код а ту еще и 10, от этого мозги «закипят» и как следствие может мучить бессонница и другие проблемы.
Как раз таки за погоней за деньгами молодые шутливые парни быстро израсходывают свой жизненный ресурс и рано сходят с дистанции по состоянию здоровья.
Уж лучше выучится на электрика и пойти отработать свои 8 часов и не думая пойти домой, нежели оставаться перерабатывать.
IT того не стоит что бы ради него себя мучить и гробить свое здоровье.
Что-то многие зациклились на
которые могут и по 12 часов без перерыва.
ты все еще про программирование?
Я вообще думаю, что нормальный предел для кодинга — это около 6 часов. Т.е. действительно
Смеялся долго, спасибо за юмор.
А если включить серьезность — давай посмотрим на ситуацию под немного другим углом: будьте так добры пожалуйста обосновать для чего Вы сами нужны такой команде ?
Каждый в команде спец, способный реализовать бизнес решение и взять на себя риски. Так что при таком раскладе именно Вы — пятое колесо в телеге. Слабое и ненужное звено, которое хочет денег. Непонятно за что.
Подумайте об этом на досуге.
Если это обращение лично ко мне, то я не могу обосновать зачем я такой команде, так как у меня команда другая и мы работаем по другим принципам. Описанный кейс совсем иной, у меня такого опыта не было, и именно своей противоположностью вызывает интерес для изучения. Я лишь могу предположить, что есть проекты в которых: а) в одиночку добиться успеха слишком сложно; б) не у каждого есть возможность работать месяцами над проектом, который не приносит прибыли; в) вполне можно получать удовольствие от работы в команде с сильными коллегами и большой степенью свободы.
И если большинство комментаторов обратило внимание на «50 часов в неделю», что возбудило желание «обращаться с жалобами в профсоюз, чтобы спасти бедных рабов», то для меня важнее другое. Неужели снижение стоимости внешних коммуникаций, автономность и готовность к принятию рисков позволяют создать такую атмосферу, в которой людям настолько нравится работать, что они не считают часы? Как в принципе создается такая атмосфера. Явно не из-под палки, организовать таким образом работу нельзя насильно. Работает ли эта атмосфера в реальности или это фантазии. И чем менее реально выглядит подход, тем больше представляет интерес. Банальные кейсы с полным жизненным циклом разработки и привычными подходами не так интересны для изучения, их и так слишком много.
Если это обращение лично ко мне
Ко всем, кто является сторонником такой концепции.
Описанный кейс совсем иной, у меня такого опыта не было, и именно своей противоположностью вызывает интерес для изучения.
Предложение поехать на машине через болото помимо дороги также вызывает интерес для изучения. Только к решению задачи перевозки из п А в Б не имеет отношения.
Без практического примера разработки серьезного продукта по таким принципам обсуждать просто нечего. Причем с цифрами в руках.
И если большинство комментаторов обратило внимание на «50 часов в неделю», что возбудило желание «обращаться с жалобами в профсоюз, чтобы спасти бедных рабов»
Вы очень невнимательно прочитали основной посыл людей.
40 часов в неделю взялись не с потолка — это практически доказанный предел, за которым при добросовестной работе начинается необратимый износ организма.
Поэтому за переработки платят по таксе 2x.
Таким образом ставя человеку задачи на 50 часов будьте так добры заплатить как за 60. О чем большинство уже написали — что резко возрастает стоимость разработки.
И внятных обоснований такому подходу нет.
Как в принципе создается такая атмосфера.
Странный вопрос. На этот вопрос давно ответили и это работает каждый день. Банально не нужно относиться к инженерам как ресурсу второго сорта. А как к партнерам. С соот. правами и долей, то есть мотивация серьезными деньгами.
В стартапах, к примеру, где люди надрываются за перспективу серьезной доли, то есть денег. там не о +200$ идет речь.
Ну или за зарплату сильно выше рыночной.
Банальные кейсы с полным жизненным циклом разработки и привычными подходами не так интересны для изучения
Эти самые «банальные» позволяют создавать серьезные и длительно живущие продукты с прогнозируемым качеством и в прогнозируемые сроки за прогнозируемые деньги. Это производство как оно есть. Вам это не интересно ?
Каждый в команде спец, способный реализовать бизнес решение и взять на себя риски. Так что при таком раскладе именно Вы — пятое колесо в телеге. Слабое и ненужное звено, которое хочет денег. Непонятно за что.
Всё так. Если это решение уровня «Hello world».
Но, как правило, требуемое несколько сложнее — и даже от трудолюбивых и опытных людей нужно, скажем, 10к человекочасов. При этом, на проект выделен год. Вот и считай, сколько таких трудолюбивых и ответственных придётся привлечь.
P.S. А наймёшь дешёвый «балласт» — проект уйдёт в утиль.
Могу утверждать: разработка действительно ускорится. В разы ускорится. Команда, если можно так назвать, покажет потрясающую велосити. И каждый возьмёт на себя риски и будет пахать почасово.
Что сказка закончилась вы узнаете, когда несмотря на бешенную скорость результат будет всё так же недостижим. Что нанятые для столь же бешенной скорости продаваны на бешенной скорости продали софт или сервис, а он оказался с бочкой дёгтя, и 100% клиентуры съебали в закат.
Разумеется, пришла пора раздать слонов, то есть риски. И тут выясняется, что риски они берут на себя тоже почасово. И что устранять системные баги они не могут в принципе, потому что код «нємножко пизжений». И по итогу 100% разработчиков свалили в закат, остались только сисадмины — готовые во сколь угодно раз растить цены на постоянно растущие потребности софта. И чем более по-дебильному написан софт, тем больше заработают админы. Разумеется, нанятые по тому же принципу, кто подешевле.
Останется мелочь: найти тех, кто доделает третьи 90% проекта за 0% бюджета. Потому что вторые 90% уже оплачены, >250% бюджета «вложено» (правильно говорить просрано). А продаваны съебали в первый же день, как только на них попытались повесить риски оттока клиентов, то есть бабла уже нет.
Результат: вы очень долго и упорно ищете «инвестора». Велосити этого процесса вам понравится — особенно весело выглядит безвозвратный поток денег на участие в ивентах, особенно закордонных. Самым впечатляющим моментом будет просадка последних денег на элитный отдых и элитный алкоголь.
Посмотрел видео — и возник встречный вопрос: а какова себестоимость при такой системе разработки?
«Тройственную ограниченность» никто не отменял: если мы делаем ту же работу быстрее — значит растет и стоимость!
При этом логика подсказывает что стоимость растет не линейно: что бы человек работал 16 часов вместо восьми он явно захочет не в 2 раза больше денег!
Получается что мы ищем в команду только очень сильных фулстек разработчиков на работу по 50 часов в неделю, с риском быть уволенным в любой момент (мы же выгоняем слабых!), с непонятными перспективами по больничным и отпускам (а кто в это время будет работать?)... И это в условиях очень перегретого рынка, где за синьоров дерутся большие галеры и где синьоры получают +500 просто за лайканье котиков в другой конторе.
Возникает вопрос: это сколько-же надо предложить что бы набрать людей на такую работу? Например от 10К баксов (это как раз по 50 баксов в час за 50 часов в неделю)?
И какие же проекты нужно брать что бы такие расходы окупились? Только самые «горящие» и рискованные? А если что-то пошло не так и не успели?
В сети не принято спрашивать про возраст — но видео больше похоже на фантазии ребенка, чем бизнесмена, который это успешно опробовал на практике. Особенно доставляет фраза что «у нас нету супер-бюджетов, мы с 30 девелоперами очень быстро делаем революционные продукты, которые другие компании делают за десятки и сотни миллионов долларов». Ну и сколько же миллионов достается каждому из 30 «чудо — богатырей»?
Уже пятница и токсичные сеньоры вернулись.
Ну вот, как и ожидалось: подающая надежды шлюпка с Виталием и его возлюбленным мальчиком Харитоном на полном ходу врезалась в плотину, сооруженную Бобром.
И пошла по харитону.
Да идите *****.
Очередной пророк и гуру бизнеса вылупился.
Автор темы — очередной цыплёнок Комо, лишь вылупился из яйца — и тотчас же стукнулся о стену коровника.
Автор, вы еще предложите всем бросать свои проекты и срочно делать новую криптовалюту. Для полноты картины.
Наконец-то правильные вопросы! А на счет оплаты, там речь идет о продукте, а не об аутсорсе. В правильном продукте денег больше.
Возникает вопрос: это сколько-же надо предложить что бы набрать людей на такую работу? Например от 10К баксов (это как раз по 50 баксов в час за 50 часов в неделю)?
Едешь в Нью Васюки, набираешь пучок сеньоров по 300 баксов и почиваешь на лаврах местного боха. Безамбиционных программеров пруд пруди, где вылупились, там и старятся.
Вот оно где фулстек-синьоры за 300 баксов будут по 50 часов в неделю работать!
А то тут некоторые жаловались что нету программистов за 200 баксов — поэтому сложно делать бизнес:
dou.ua/...nta/columns/sad-but-true
А то тут некоторые жаловались что нету программистов за 200 баксов
Есть такие программисты. За +200 баксов перейдут на галеру через дорогу.
lifehack: открыть 2 конторы с обеих сторон дороги
Заслуженная слава:
«Это просто полнейший пиздец. И находятся же долбоёбы, которые готовы работать на таких условиях?»
Игнайт со своим коровником рассчитывают, например, на короткую память у людей.
Непрерывно ищем более сильных и классных
Всё правильно- надо чтобы только альфачи работали на проекте. Сильные- так чтобы 100 жал за раз отпола не краснея. Классный- ну вообще классный.
Прощаемся со слабыми
Что то вспомнилось: вы самое слабое звено © — голосом ведущей.
Вовлекаем в работу более 40 часов в неделю
Вот это понимаю ноуХау. Съездите в европу на саммит менеджеров- раскажите германцам, нервейцам, денмаркцам и другим лидерам тратап культур в европе- что их идеи о км/ч засов в неделю
Движение в сторону фул-стэков
Вот это ясщитаю правильная мысль. И вообще 2019 год объявили годом javascript.
А то напридумывали там каких то законом Мура. Производительность железа растет, память дешевая. Даёшь блокнот по заметок съдающий 2 гига памяти с подгрузкой всего из интернета. И конечно же надо переплюнуть биткойн мейнеры по загрузке процессора — на каждый чих в приложении. Всё будет жаваскрипт
Мы не боимся ошибиться. не надо бояться уронить продакшн, но надо позаботиться, чтобы в
Вот всё жду когда ваши адепты начнут разрабатывать автопилоты машин
Тогда всем вокруг прийдется
учиться двигаться быстро
чтобы такие домой добраться живым.
Потому что система автопилота разрабатывалась с мыслью что:
случае его падения была затронута небольшая часть пользователей
Подумамешь — кого то задавит- ну так всёравно перенаселение в африке.
Ну и конечно, я больше не удивляюсь таким темам как «пропал swift платеж» и тд
Мы умеем бороться с последствиями
В авральном режиме в 2 часа ночи по 3G каналу конектится в проду на другом материке- только для того чтобы обнаружить что логи то некто не пишет- ибо нет времени на это =)
Ну чего — тут недавно в какой-то теме мелькала статья про Маска, и там все похоже на стартап обыкновенный. Так что допустили.
Если «самый главный» рандомно приходит на завод, психует что объемы производства не такие как он хочет и увольняет первого попавшегося инженера — то что-то там работает разве что чудом, титаническими усилиями работников и вопреки, а не благодаря «самому главному»
и увольняет первого попавшегося инженера
Не первого попавшегося, а идиота.
И Маск прав. Идиотов нужно выкидывать на морoз, а толковых людей привлекать и оставлять. Тогда ракетки будут летать и на платформы садиться (что у него и происходит).
Мы вообще в ветке про машинки, а не ракетки. И с машинками что-то не так уж всё и хорошо. Производство налаживается долго, машинка может не поехать после апдейта прошивки по воздуху, автопилот может не разглядеть грузовик на фоне неба
А еще вынуждать пахать пока нп сдохнешь и в ущерб семье ради идеи, если нет — на мороз.
Куча статей про «рай» с спейсХ и Тесле.
А еще вынуждать пахать пока нп сдохнешь и в ущерб семье ради идеи
В смысле, ради идеи? Хотя, если назвать скажем 200-250/час «идеей» — то ок.
Идеей называется патриотизм к проекту
Да хер на него положить! Вот странные эти жулики: ищут дурачков среди людей заведомо умнее их. Когда не находят пишут статьи с основной мыслью : программисты зажрались и за идею не работают. Когда спрашивают: " в чем идея?" — становятся агрессивными. Когда намекаешь, что мол вот этот стул хорош для ломания о дурную голову агрессивного сопляка возомнившего себя директором резко сменяют тон на «все люди братья»
Вот странные эти жулики: ищут дурачков среди людей заведомо умнее их. Когда не находят пишут статьи с основной мыслью
великолепно сформулировано!
И главное никого конкретно не оскорбил. Речь если что не о авторе, а вообще — с первым я не знаком. Встречал я одного такого «менеджера» году этак в
А то ходють тут усякіє, токсинами попердують, панімаєшь, токсичні неусміхнені падлюки!
Стараемся вовлекать членов команды в работу около 50 часов в неделю, вместо стандартных 40.
Оплата защекоинами?
Автор, вам повезло, что еще не пятница и токсичные сеньоры еще немного заняты.
Булшит от менеджеров. Для тех кто такое пишет неплохо было бы восстановить лагеря. Немецкие, ведь менеджменту положено самое лучшее!
Дякую! Щиро дякую таким авторам, що самі допомагають поповнювати ЧС контор, у які особисто я і пос**ть не зайду, хай навіть в них буде останній сортир на районі.
Так от мимохідь зізнатися у постійній текучці та потогонці — це ще вміти треба )
Після ЛСД код-рев’ю не пройде )
ревьюверы должны быть тоже под ним.
Я знаю один науковий метод — підсипати девам в чай ноотропи.
в горнятко
про «горнятко»
це мемчик звiдси: jobs.dou.ua/...panies/luxoft/reviews/59
Потім стикнувся з такою річчю шо працівники проекту
підливали в горнятко з водою
якусь рідину без смаку шо має галюциногенні і гіпночичні властивості
потім наскільки я зрозумів дана процедура називається «зомбізацією».
Автор отзыва — параноик еще тот.
В горнятко с водой подливали... такую же воду, чтобы она в горнятке не заканчивалась.
Другой вопрос , что это могли очень с загадочным видом делать и странно поглядывать краем глаза — что и могло насторожить автора отзыва. За зомбизацию чаще всего ответственный офис-менеджер, чуть реже — уборщица или самый неприметный коллега на этаже.
«кратно ускорили» парня, оверклокнули:
На проекті з мене знущалися дійшло до того що цілу ніч працівники проекту
сиділи в моєму під’їзді не давали мені спати стукали в мої двері і погрожували моєму життю.
Так мене перестрашили шо я перестав заїкатися(((
Ше після цього всього мене було безпідставно звільнено прожект менеджером.
Після цього мені прийшлося місяць лікуватися в Моршині шоб відновити своє здоров’я.
Від фірми за дані дії я компенсації так і не отримав.
Стараемся вовлекать членов команды в работу около 50 часов в неделю, вместо стандартных 40.
Да идите *****.
Очередной пророк и гуру бизнеса вылупился.
Очередной пророк и гуру бизнеса вылупился
плюсую за мягкость формулировки
классика: чтобы корова меньше ела и больше давала молока..
Ну почему, ставка за час 80 баксов и я согласен работать 50 часов
50 часов это 10 часов в день — длинный обед, больше походов на кофе и разговоров о жизни и зачет
Так если какие-то дебилы дрочат на часы то этим надо пользоваться
Поставят тайм трекер и будешь кодить, обедая и запивая кофе одновременно.
об этом не говорилось, но я на такое даже на 40 часов не пошел бы, максимум 30 часов, но ставка тогда должны быть еще больше
В принципе даже
Ну че, можно следующие недели 2 клевать носом с производительностью процентов 20, и то только на несложных задачах. Но это все равно не отдых и никак не подготовит к следующему
Это всё индивидуально. Если у тебя от 60 часов/неделю разрушается мозг и потом 3 недели нужно его восстанавливать — значит, не видать тебе серьёзных проектов и серьёзных денег.
У мене подруга працює на 2 роботах,
Коли здоров’я підірване то вже не радують сири за 500 гривень і смузі намазане на хліб.
В неї із психікой тоже є деяки проблеми, порушеня сну, роздратованість, різки перепади настрою і т.д.
Если тебе надо 60 часов пахать в неделю, причем постоянно, то тебе тем более никогда не видать серьезных денег. Вообще о каких серьезных деньгах может идти речь на наемной работе? Смех просто.
Если тебе надо 60 часов пахать в неделю, причем постоянно, то тебе тем более никогда не видать серьезных денег.
Я лишь в этом году — отпахал чуть более 2500 часов на проекте. За это время выгреб чуть менее 250к. И это уже не первый год в таком режиме. Пока полёт нормальный... :)
Ты живёшь чтобы зарабатывать эти самые 250к, или зарабатываешь их чтобы жить?)
Ты живёшь чтобы зарабатывать эти самые 250к, или зарабатываешь их чтобы жить?)
Сейчас живу чтобы зарабатывать, в основном. Но надеюсь на кризис не позднее 2020 — тогда и поживу для жизни. :)
Прикинь, у тебя случится инфаркт. Вот обидно будет.
Прикинь, у тебя случится инфаркт. Вот обидно будет.
Работаю 5 дней в неделю. Хорошо жру, сплю и сру. Откуда взяться инфаркту?
Оно, скорее, инфаркт может случиться в Украине — когда на съёмную квартирку нагрянут налоговики или бандюки, да отожмут сумку со всем баблом.
Только у меня дома нет сумки с баблом
Только у меня дома нет сумки с баблом
Что ты, Владимир, начал доверять свои деньги банкам? Не может быть!
П.С. А вообще, работа 60 часов/неделю — это ни о чём. Напрягает долго работать 80+ часов/неделю. Но это нужно уже минимум по 6 дней/неделю «на дядю» работать — что многовато, т.к. есть и другие дела.
Что ты, Владимир, начал доверять свои деньги банкам? Не может быть!
Я шо, лошара? Мои деньги заныканы у разных людей которым я доверяю и никому кроме меня они их не отдадут. Где прячут я не знаю, но надежно То есть, даже вариант с похищением не катит — за баблом нужно придти лично, а каким то тварям в погонах не отдадут тем более
А вообще, работа 60 часов/неделю — это ни о чём
Мне больше шест часов в день кодинга чистыми уже тяжело. Надо ещё и думать
Мои деньги заныканы у разных людей которым я доверяю и никому кроме меня они их не отдадут. Где прячут я не знаю, но надежно
Лол, просто лол.
Я доверяю, понимаешь о чем речь? Гораздо больше, чем банку
ебанашка из менеджмента
Выделил главную мысль.
Какие
Напоминю старую истину «10х программисты требуют 10х рабочее окружение». В обычных условиях они показывают обычный или нулевой результат.
Пока софт уровня «нарисовали кнопку, добавили метод в контроллер и поле в базу» — можно брать фулстеков. Когда софт станет сложнее и начнутся тормоза в базе(например) — всё равно придётся звать DBA и платить ему нехилые деньги.
Ну или нанимать таких специалистов, которые не постесняются оптимизировать бд. Об этом и пост :).
Чтоб оптимизировать БД — нужно знать как это делать. А читать одним глазом книги по фронту а другим по БД — не очень получится. Либо работать по 50 часов в неделю(как предлагает ТС) и ещё учиться часов 30 чтоб всё знать. Очень интересная жизнь получится.
Чтоб оптимизировать БД — нужно знать как это делать.
Или куда смотреть — это де не rocket science. В контексте темы мы же обсуждаем опытных, разносторонних специалистов, а не тех, кто веб 10 лет пилят.
Еще скажи, что с таксером сложно сдавать отчетность.
Из серии: на бумаге я синьор c++, java, .net, php, python ну и еще с десяток технологий ))
а по факту по пол года опыта в каждой сфере :)
Синьорам платят не за знание яп/технологий, а за решение проблем и дотягивание проекта до релиза.
И если синьору понадобилось за недельку освоить какой-то фреймворк или там яп, чтобы на нём чего-то дописать — у него будет соответствующий опыт с этим фреймворком/яп. Скажем,
соответствующий
В этом и весь смысл :) И вы не сравнивайте подтянуть какой то фреймворк и задачи для DBA. Как ни крути — это вообще отдельный мир.
У, например, меня по-другому: довольно хорошие знания .NET + на одном проекте нормально вник в SQL Server, в другом — в MongoDB, в третьем — EventStore, в еще одном по косточкам разобрал Angular 2, в еще одном Polymer, до этого было много JS, jQuery, knockout.js. Плюс понимание того, как строить надеждые распределенные системы. И во всем этом я достаточно глубоко разбирался. Вот и получается специалист, который может на себя полностью взять ответственность за поддомен, например.
Мне кажется, ключ тут хорошо разбираться с интрументами/подходами когда встречается задача, а не хуяк-хуяк и продакшен.
То есть вы сейчас на уровне сильного DBA с SQL Server ? Сможете быстро решать типичные проблемы/задачи, с которыми DBA сталкиваются в сложных хайлоад продуктах? Уверены?
Зачем же утрировать. Но, да, приходилось делать нетривиальные оптимизации в SQL сервере и вникать во внутренности монги, в частности, в механизм репликации.
В том что теоретически вы можете таки решить любую задачу на любом языке (или любой технологии) я конечно соглашусь. Но вопрос во времени (а мы же создаем «быстро работающую» команду), у вас нет времени разбираться, вы должны все это знать
А-а, я понял в что ввело многих тут в заблуждение. Идея увеличения производительности в том, что тебе не нужно ждать пока у товарища появится свободное время решить твою проблему, а ты можешь ее решить самостоятельно. Если не получается в разумные сроки — тогда эскалировать. Для каждого отдельно взятого тыжпрограммиста решение может занимать больше времени, но общая производительность команды/компании будет расти за счет снижения блокеров и зависимостей.
Как в твоем примере ниже, задачи у фронтендера могут быть расписаны на неделю или на месяц вперед и у него нет времени фиксить твои баги. Следуя твоему подходу фичу выкатят через неделю/месяц, если ты ее сам решишь сегодня — то уже завтра. Образно говоря, естественно.
С одной стороны все верно ) а с другой — затраты на реализацию фичи? тот же чистый фронтер её сделает в полтора раза быстрее (и дешевле в полтора раза). А для компании важно что? конечно — исключительно заработок и как можно меньшая себстоимость затрат (для компании) на 1 фичу.
Опять же, если вернуться к примеру, если фичу не зарелизить вовремя ввиду загруженности фрондендера, потом, когда у него появится время, может быть фича уже и не нужна будет, так как конкуренты заполучили рынок. Будь эта фича хоть бесплатна.
А что есть «загруженность» фронтендера в таком случае? вы уже описываете ситуацию, когда фронтендер работает на несколько проектов сразу? Если это 1 проект клиента (большой) — то если у клиента больше хотелок, чем может выдержать фронт разраб, то клиенту нужен еще 1 фронт забработчик на оклад, и проблема решена. По другому не бывает :) А если несколько проектов набрать и как то выкручиваться — тут соглашусь, фулстаки могут иметь определенное преимущество. Опять же, если клиент готов платить только за 0.3 от фронта нагрузки, он должен понимать, что он не будет в приоритете.
По другому не бывает :)
Вот собственно топик о том, что бывает. Ладно, я буду считать, что свою мысль у меня донести получилось, а вы вправе оставаться при своем мнении.
чистый фронтер её сделает в полтора раза быстрее (и дешевле в полтора раза).
т.е. ТС просто не на том концентрируется. чтобы запилить проект в полтора раза быстрее и в полтора раза дешевле, надо просто мыть фронтеров (кто бы это не были)
Есть же специальные ошейники...
тот же чистый фронтер её сделает в полтора раза быстрее
Скорость/продуктивность зависит не от знания технологий, а от умения работать.
Скажем, у меня продуктивность примерно в
Но кто-то пашет, а кто-то расслабляется, «социализируется» и пьёт кофеи.
В этом, а не в знании фреймворков разница.
не гоже тратити час на доу
Я с четверга до конца года отдыхаю — так что, можно и «посоциализироватъся» на ДОУ. :)
З таким баблішком на рахунку я б десь на Мальдівах увесь вільний час посоціалізувався)
Мальдивы — они расслабляют. А нужно сосредоточенно пахать до кризиса, т.к. баблокос. А там можно и расслабиться на годик-другой-третий..
К тому же, ко мне родственники из Украины послезавтра приезжают на 2 недели. Так что, не до Мальдив...
Та может он в палате в усмирительной рубахе сидит, а перед праздниками пустили к компу :-))
у меня продуктивность примерно в5-6 раз выше, чем у среднего разработчика
Пишу со скоростью 200 слов в минуту.. правда такая херня получается.. )))
Коментар порушує правила спільноти і видалений модераторами.
Но кто-то пашет, а кто-то расслабляется, «социализируется» и пьёт кофеи.
о, чиста Швеция.
а потом они на тебя же еще косо смотрят — мол асоциальный типчик
Так не всем проектам нужен сильный DBA с опытом в сложных хайлоад продуктах
Тут согласен. Но речь совсем о другом. Рассматривается некая идеальная команда в теме, и с подходом в виде пачка универсалов и точка — я не согласен. Я много работал и фулстак, много работал с разделением бекенд/фронт — второй вариант намного приятнее, когда я пишу бекенд, и есть налаженное взаимодействие с фронт-разработчиком. Ибо бывают на фронте у меня задачки, где приходится потратить время на поиск проблемы, а фронд-разработчик (а стажа у него на фронте разумеется х2, как минимум) это давно уже прошел, и с закрытыми глазами такие вещи решает, тратя по 5 минут. И как devops я никакой. Нельзя везде быть сильным специалистом (ну исключение, наши 18летние синьоры, которым по пол года нужно, чтоб стать синьором еще в очередной сфете :) ).
Я согласен что нельзя везде быть сильным и склоняюсь к разделению бек/фронт. Но не везде умеют разделять так чтобы не было простоев например. И чтобы разделять и правильно всё сделать — нужно больше времени, а тут бизнес, конкуренты в попу дышат, да и вообще чего так долго и дорого.
Я вот шушуть поднаброшу в ваш уютный срачик о фуллстек-вс-разделение. Я вообще сам тоже за разделение, но в фулстеке есть плюс. Когда фулстековость не ставится принципом, а идет бонусом, это в целом повышает эффективность работы как бекенда и фронтенда отдельно, так и их обоих в сумме. Потому что если взять двух сферичновакуумных разработчиков, которые шарят только бек и только фронт, между ними понадобится человек, который будем синхронизировать им переставление ног, чтобы они не споткнулись друг об друга.
между ними понадобится человек
Нафига он там? Это что дети чтоль, которые договориться не могут?
Фулл стэк хорошо когда когда какая-то сторона не требует высокой квалификации:
простенький фикс или расширение функционала по примеру который уже есть в коде,
когда есть лид фронта или бэка который смотрит чтобы не присовывали откровенное говно или берет на себя что-то сложное чтобы дев из другого лагеря не тратил джва дня на то что у него займет пару часов.
Это что дети чтоль, которые договориться не могут?
А ты никогда не встречал ситуацию, когда вот человек в своей сфере просто рок-звезда, а взаимодействие с рок-звездами с другой сцены не клеится, потому что моя твоя не понимать?
В каждой сфере своя специфика, и если один инженер строит офигительный паровоз, не интересуясь рейками, а другой прокладывает трансконтинентальное полотно, не интересуясь паровозом, который будет по этому полотну ехать, в конце концов получится ситуация, когда ширина полотна и колес будет разной.
Ну мне кажется это проблема мидлов, синьор должен понимать ЧТО он делает и ЗАЧЕМ. Ибо в противном случае за всем нужен глаз да глаз. Но то что эта проблема есть я не отрицаю.
синьор должен понимать ЧТО он делает и ЗАЧЕМ.
Проблема вообще не в понимании что и зачем. Проблема в подходах. Один человек может считать что правильно — так, другой что правильно — так. Оба делают хорошо и правильно, но в процессе оказывается, что снежок не лепится.
но в процессе оказывается, что снежок не лепится.
Значит не правильно :-) Ну честно, зачем для двух программистов еще один передаст?
Не для двух программистов. 1 ДБА, 1 лид бекенда, 1 лид фронта, 1 лид девопс, 1 лид какихто внешних интеграций. ДБА считает что правильно логику выносить в базу, бекенд считает что база только хранилище. Бекенда наделал ендпойнтов по ресту, а оказалось что оно отдает фронту неудобные форматы, причем неудобные именн с т.з. логики фронта и т.д. Каждый делает нормально, но между ними нужен тот, кто скажет кому в какую сторону идти чтобы телега поехала в одну сторону, а не в разные.
Фуллстековость участников позволяет взглянуть на сферы соучастников с их т.з. и адаптировать свою работу к их нуждам. Или даже сказать «эй вы что творите» если коллеги на своей стороне начинают какуюто дичь воротить.
Та камон, по фиче делается митинг не большой, где эти чуваки решают какой формат и где логика. Всегда так работал, зачем мне какой-то лид чтобы выбрать формат данных на фронт? Ты ща пишешь схему для джунов.
Соглашусь с тем, что какой то уровень знаний и опыта в смежных технологиях только в плюс.
между ними понадобится человек, который будем синхронизировать им переставление ног, чтобы они не споткнулись друг об друга.
ну если брать сильных опытных синьоров (мы ж идеальную команду обсуждаем) — то каждый бекендер закрыл десятки проектов в синхронизации с такими же синьор фронтендерами, и все прекрасно понимают как им между собой синхронизироваться. А если кто то не понимает — всё легко, кто с бОльшим опытом — тот и определяет «интерфейс» взаимодействия. Сколько раз работал со слабыми фронтерами — все было очень круто, потому что они просто слушали и делали так, как я просил ( в плане обмена данных )
может так случится, что у тебя поверхностные знания везде и есть определенная планка выше которой ты не можешь шагнуть, только там где работаешь планка низкая и все кажется что хорошо, проверяется только тем что искать банду узкоспециализированных типов и просить их тебя оценить по их меркам в их области
онимание того, как строить надеждые распределенные системы
Вот прямо таки понимание?
Меня тут особо заинтересновало слово «надежные»
т.е. вы знаете как сделать систему надежной в условиях реальной боевой эксплуатации?
К тому же еще и распределенной система будет?
Т.е. если система распределена георафически между континентами и вдруг начали возникать высокие задержки в вашей надежной системе- вы сможете определить что это вина магистрального провайдера канала связи и сможете отлечить проблему от задержек возникающих из хардварных проблем в одном из коммутаторов mac address flapping? Ну конечно же си сениор сможет предусмотреть в своей надежной системе алгоритмы компенсации случайных перезаписей ячеек памяти вызванных случайным облучением одного из серверов космическими лучами?
Похоже сейчас модно всем сениорам говорить что они знают как построить «надежные, распределенные системы» — это примерно тоже самое как каждый первый датасаентист — утвержает что может строить state of the art модели для чего угодно.
Надежность системы определяется тем, как она будет реагировать на подобные задержки. Нет, конечно, я не настолько крут, чтобы построить свой AWS.
Само собой. Я отвечал в контексте комментария.
хрень + блокчейн стоит раза в 2 дороже, чем хрень без блокчейна
вон сейчас какято дурная манечка — телефоны с блокчейном
+ на одном проекте нормально вник в SQL Server
Просто лол. Я 12 лет уже скоро занимаюсь SQL Server и даже близко не знаю всего что там есть. Как вообще можно быть синиором без хотя бы 5 лет работы с одной субд?
И я не знаю всего, лол. Более того, все знать и не нужно. Нужно разбираться хорошо в том, что используется. И иметь представление о том, что доступно, чтобы вникнуть при необходимости. Кстати, как раз с SQL Server работал порядка 6 лет.
Все знать и не надо, надо знать общие принципы( транзакции, джойны, профилирования запросов, как заставить БД выполнять все именно так как вы хотите — по индексам и так далее, понять почему БД не хочет с вами соглашаться) и знать где лежит документация.
При определенном навыке «фул стек» вы будете сами догадыватся, когда вам нужен узкий специалист(и происходит это, мягко говоря, не часто, даже в нагруженных системах).
Возможно, он вам и не нужен, например, проще заменить часть сложных джойнов быстрыми короткими выборками в aerospike и заодно разгрузить точку наибольшей нагрузки — SQL Server(у нас так было недавно, и узкие специалисты нихрена не справилися, поскольку джойнами тянулися индексы по 100гб таблицам, а они говорили «ну по другому не получится, вам бы сюда 500гб памяти»).
всё равно придётся звать DBA
дба уже не поможет
Причем чем позже звать — тем больше придется платить, т.к. влазить с оптимизациями в уже сделанный через пень-колоду продукт — задача нетривиальная.
А коли гребці видохнуться і здохнуть, викинути їх за борт («Прощаемся со слабыми») і купити на ринку нових.
Ну так в Китаї і Індії так і роблять.
Ну так: «нічого особистого, лише бізнес».
Правильно он говорит. Только таким специалистам нужно платить сильно выше рынка. Если с оплатой проблем нет — будет работать. И, ведь, он проговаривает не новые вещи.
«Маленьким продактом» без делегации полномочий стать как минимум очень сложно. Чем больше зарываешься в текучку тасков, тем сильнее тает видение общей картины и может снижаться адекватность решений. А если овертаймить постоянно, то вопрос времени, когда это произойдёт.
Тут є підозра, що якщо взяти людей, кожен з яких краще рядових мідлів-сіньйорів в більшості контор, то вони напишуть, з великою долею йморівності, хороший продукт незалежно від того, озвучити їм вищенаведені принципі чи ні, хіба хтось почне явно вставляти палки в колеса.
Такі люди вже б мали достатній досвід аби розуміти, як правильно, а як ні.
Брать высококвалифицированных и дорогих, вместо недорогого «балласта» — это правильный концепт.
Единственная опасность, что каждый из таких «дорогих» будет носителем «ноу-хау» своей части и если выпадет по какой-то причине из проекта — «ноу-хау» этой части проекта выпадет вместе с ним.
С другой стороны, «дорогие» хороши тем, что быстро въедут в чужой код и погребут дальше.
для маленьких приложений или мобайла САБЖ применим, думаю.
Для энтепрайза — нет.
Для геймдева — частично.
Для ритейла — хм, интересно будет узнать, за какое место подвесят цэо-шника
мобайла
Да, понапишут фуллстеки на реакт нейтиве приложения, а потом они жрут по 100-200МБ оперативы (при том что полностью нативное потребляет почти на 70-100МБ меньше), и заказчик потом ругается че так все всрато и глючно.
потом они жрут по 100-200МБ оперативы
это еще относительно неплохо
Да, понапишут фуллстеки .. а потом они жрут по 100-200МБ оперативы
да, но вопрос в сабже про «быстро», а не про «качественно»
Да, только какой смысл от этого быстро, если оно будет потом крашиться от out of memory.
а смысл делать качественно, если на это ресурсы не запланированы?
перечитайте pls сабж,
особенно финальный пункт.
«Принять риски» — т.е. овертаймить и выгорать.
Прям все, что описано подходит для «типичного аутсорсера» уровня дна или чуть выше.
Skyeng вроде как продуктовая компания и если они работают по таким принципам, то это печаль...
Из того, что я собрал по отдельным окошкам (очевидно просто написать тезисы было не модно).
— Работа 50 часов в неделю.
— Каждый девелопер делает фронт, бэк + девопс. Тестит очевидно то же сам.
— Модули автономные, но если девелоперу что-то нужно в чужом модуле то он должен сам в него вникнуть и починить.
— Вместо закладываться на будущее мы педалим быстро и потом быстро разгребаем последствия наших быстрых решений.
Как считаете, для кого применим такой подход, а для кого нет?
ИМХО, применим для небольших, «одноразовых» проектов на заказ: быстро налабали — быстро спихнули, быстро получили профит.
На долгосрочном проекте вылезут проблемы такого подхода:
— Что бы набирать только самых классных и «универсалов» на 50 часов — им нужно платить хорошо выше рынка. Что делать если временно работы на всех не хватает? Выгонять и потом опять искать?
— Люди не могут постоянно напряженно работать по 50 часов. Через Х недель производительность начнет падать или упадет качество.
— Специалист во всем — специалист ни в чем. Очень часто вместо лучших решений от «универсалов» будем получать быстрые, но не слишком удачные. А экспертов нет — некому подсказать.
— Следствие быстрых решений — технический долг. Он имеет тенденцию накапливаться незаметно. Но в какой-то момент вылезет — и окажется что быстрого решения уже нет. Так умирал ни один проект.
Как это работало по моему опыту:
В период спада спроса на «попачасы» компания решилась брать фиксед прайс проекты.
Собрали «команду мечты» из синьоров: отдельно фронт, бэк, мобаил, QA, DBA + девопс и толковый менеджер. Девелоперам платили ставку + солидную премию если успели сделать и сдать проект в срок и без багов. Поэтому у команды был интерес делать хорошо и овертаймить если надо.
Проекты брали продолжительностью до полугода ± пару месяцев. Соответственно после успешной сдачи проекта часто была пауза (от недели до месяца), когда команда могла отдохнуть.
Команде такая схема работы нравилось: можно было хорошо заработать, и потом отдохнуть. Плюс моральное удовольствие от успешно сделанного проекта.
Но для компании такая модель была очевидно менее выгодная, чем продавать «попачасы», поэтому как только набрали унылых сапортных проектов — «команду мечты» разогнали.
Для небольших, «одноразовых» проектов на заказ — согласен. А если говорить о продуктовых компаниях? Которые считают, что главное — скорость создания чего-то, чем смогут пользоваться клиенты?
А если говорить о продуктовых компаниях?
Это как научиться жонглировать. Подбрасывать один мячик — легко и просто и все получается на отлично. Подбрасывать два — уже сложнее... И чем больше добавляется мячиков — тем больше вероятность ошибиться и все посыпется на голову...
Делать свой продукт «на скорость» без долгосрочного планирования и не закладываясь на будущее...
С точки зрения бизнеса в этом может есть смысл: опередить конкурентов, быстрее проверить идею, захватить рынок... Для стартапа — может быть и прокатит.
Предположим что идея «выстрелила» и количество пользователей растет. Выросло в 2 раза, в 5, в 10... А потом оказывается что система больше не тянет! И банальным увеличением ресурсов уже не лечится. Нужны радикальные изменения архитектуры: например переход от монолитной базы к микросервисам.
Или другой сценарий: клиенты просят все новые фичеры и побыстрее. Мы быстро добавляем, добавляем, добавляем... Но надо и старые не сломать — поэтому никакого рефакторинга. Система постепенно превращается в «франкенштейна» собранного из кусков и перключателей. Потом при добавлении следующего мега-срочного и мега-сложного фичера начинают бесконечно лезть баги: починили один — вылезло два!
Есть понятие «технический долг»: все, на чем ты сэкономил при быстрой разработке — рано или поздно вылезет в самый неподходящий момент. И часто по этой причине неплохие проекты умирают: потому что развиваться дальше не дает долг, а остановиться и «выплатить» долг не дает бизнес (за это время конкуренты съедят, а клиенты разбегутся).
Я видел много таких «мертвых лошадей»: проект уже умер под своим весом, но выбросить жалко (еще какие-то клиенты есть) — их годами «хоронят» на галерах. Потом меняется менеджмент, компания продается, на убыточный проект обращают внимание и в один день могут все закрыть.
Для проектов на заказ это обычно не важно (пускай лох платит пока не обанкротиться), но если это продуктовая компания и свой продукт — такой подход к «быстрой разработке» это путь в могилу! Разве что успеть быстро продаться, пока продукт совсем не протух.
Наверное, если так и делать, то надо вовремя начать разработку параллельной версии 2.0, вероятно, другой командой, для создания продукта, потребность в котором подтверждена рынком, но подготовленного к дальнейшему развитию. И тут надо вовремя перестать тянуть эту «лошадь».
И это правильный ответ!
Выпустив первую версию продукта и подсчитывая барыши — нужно стразу начинать строить новую версию «с нуля». Потому что с момента начала разработки первой версии уже прошел не один год, а до окончания разработки и запуска второй пройдет еще не один.
За 5 лет в мире ИТ уже все радикально меняется. Микросервисы, облака, ИИ, бигдата — вспомните что «выстрелило» и стало мэинстримом за прошлые 5 лет. Поэтому нет смысла пытаться догонять пихая новые фичи в устаревшую архитектуру. Проще начать делать новое по-новому.
К сожалению такое решение требует во-первых серьезной смелости (предложить переделать успешный продукт!), а во-вторых серьезных денег. Фактически риски и затраты такие-же, как инвестировать в новый продукт. Осторожность подсказывает что лучше продолжать доить старую коровку пока не сдохнет — и большинство так и делает.
Хороший пример — это Майкрософт. При Балмере они до последнего держались за свои старые решения. За тяжеленные винды, эксплорер, за тяжеленный гуишный мс-офис, эксченж и прочие энтрерпрайз решения. У МС была «своя атмосфера» и они принципиально не хотели смотреть по сторонам.
Итог очевидный: настала «мобильная революция», эра веб-приложений, гаджетов, легковесных программ... Монструозная винда и старые программы уже никак невозможно было к этому приспособить. Пресловутая Windows 8 стала доказательством что дохлая лошадь не побежит как ты ее не покрась. И конкуренты их обошли по всем фронтам.
Благо в МС сменилось руководство и новые боссы сумели признать что старое должно умереть и нужно делать новое, ориентируясь на современные реалии. Виндофоны не нужны, эксплорер + эдж — отстрой, люди накупили макбуков вместо винды, андроид на каждом втором гаджете? Нужно уметь принимать реальность — похоронить «мертвых лошадей» и интегрироваться с чужими успешными решениями! Делать «новую версию» с нуля — пускай даже под Линукс или Андроид.
К сожалению большинство энтерпрайз компаний развели такую бюрократию, что они готовы продолжать тратить миллионы на свои старые убыточные системы, вместо создания современной альтернативы. А «галеры» на этом зарабатывают продавая им «рабов». Но это только до тех пор, пока рынок не даст пинка — и тогда придется шевелиться.
Выпустив первую версию продукта и подсчитывая барыши — нужно стразу начинать строить новую версию «с нуля».
Зачем, ведь у нас всё работает? Создается тикет «оптимайз» и пишется деву «плиз эстимейт». Всем видом показывать что дедлайн вчера и вообще там делать нечего, не синьор штоли?
Скажи-ка, гениев бизнеса шквал негативных комментариев от непосредственной целевой аудитории на какие-то мысли наталкивает?
Думаю, что на какие-то натолкнули бы. Жаль, нет возможности у них это выяснить. :) Если Skyeng действительный так работает, наверное, им это позволяет рынок труда, где они находятся.
Осталось только найти фуллстека, максимально автономного, принимающего на себя риски, очень-очень сильного, согласного работать более
и на столько глупого, чтобы он работал на тебя вместо апворк
Эмм. А если платить там будут больше, чем на апворке можешь найти проект?
Осталось только найти фуллстека, максимально автономного, принимающего на себя риски, очень-очень сильного, согласного работать более40-ка часов в неделю
Я примерно так работаю. Правда, не в веб-хипстерщине, а в хардкоре (от хардварного контроллера с обвеской, до виндовых окошек и впф-контролов).
Получаю за свои нормальные 250 часов/мес — порядка 23к. На апворке больше платят?
Получаю за свои нормальные 250 часов/мес — порядка 23к. На апворке больше платят?
?
23к чего?
Гривень. Чего же ещё? Ведь именно за гривни работают очень-очень сильные и согласные на 250/мес.
Рейт под сотку с такой загруженностью это сильно. Можете вкратце описать ваш путь к такому результату?
Опыт большой, довольно-таки специализированный (медицина, индустрия), разговорные английский/немецкий, хорошие и отличные отзывы счастливых клиентов.
А так, на проекте всё довольно интенсивно. Хотели было ещё пару человек добрать (сейчас я, некрепкий мидл и практикант накрываем софтовую часть) — но посмотрели, что хорошо тяну и вместо усиления накидали мне часов. Так и гребу, уже
P.S. Но вот теперь засомневался. Может, мне на апворк надо?
По грубой оценке получается 500 000€ заработков, минус налоги понятно, всё такое...
За расходы на жизнь не говорю, какие там расходы, если работать Каждый день без выходных.
Не хотелось остановиться и уйти на заслуженный отдых, ведь засоленных евро хватит на всю оставшуюся небедную жизнь?
Тоже на такой же игле (до 23 правда не дотянул, хотя, если чистыми, то возможно. Но и работаю по пару часов в день), но мысли завязать приходят всё чаще.
Кризиса жду — тогда и отдыхать буду. Годика 3...
Макс! Ты? Опять акк забанили и пришлось новый заводить?
И ты вот реально думаешь, что топикстартер столько платит? Да и с графиком.... Нафиг тебе деньги, если их некогда тратить?
Я 5 дней в неделю работаю. 2 выходных + праздники — мои (правда, сильно много без крупных покупок, тратить не получается)
Для книжек существует школьный возраст. А спорт в выходные. Литробол. :)
ТС наверняка копия «собирающего кораблик в бутылке», — сначала он биржевой магнат с доходом от 1 000 000$ и ищущий высококлассных специалистов на ставку выше средней программисткой по США, а через пару часов переобувается в воздухе, и готов с барского плеча выделить 1500$, и то, если выложишь из букв Ж О А П слово СЧАСТЬЕ.
Со здешними галерами иметь дело — себя не уважать.
П.С. Он из Харькова. Там на галерах 2500 синьору — за счастье и подарок судьбы.
Ну не скажи...3-ку не проблема найти вообще. А вот выше 3.5 уже посложенее будет, если не хочешь лидом быть.
3 не проблема, потому что это ниже средней, а чтобы получить выше рынка надо чтобы звёзды сошлись, вот и все. С лидом тоже — самое средняя 4, поэтому на 3.5 зайти проще. Ну и само собой на ниже рынка ищется неделю, средняя недели две, а на процентов 30 выше средней искать обычно больше месяца
П.С. Он из Харькова. Там на галерах 2500 синьору — за счастье и подарок судьбы.
Вы заблуждаетесь :)
На апворке больше платят?
Не все так просто. Вот смотрите. всего 104 человека таких(если загрузка 40 в неделю −1000 за 6 месяцев).
Если что, я туда не попадаю( попадаю если убрать «за 6 месяцев»).
А тут в условиях задачи 50 часов в неделю без перерыва. Вот их всего сотня из миллионов. И, подозреваю, из этой сотни 99 — аккаунты галер фейковые.
Разве галеры пасутся на апворке ? Мне кажется это не их поле. Вот конторы и конторки из
А как вы искали по загрузке за период?
А там нет чеклиста, как девять беременных женщин могут родить за один месяц?
надо просто быстро двигаться в сторону фулстеков
надо просто быстро двигаться
При скорости движения близкой к скорости света время начинает замедляться и в итоге мы успеваем сделать в кратно раз больше. Профит.
Если я правильно помню, то «При скорости движения близкой к скорости света» если на объект действует некоторая сила, то масса (m) объекта стремится к бесконечности (F = m * a), в силу того, что ускорение (a) стремится к 0 (т.к. объект не может двигаться быстрее скорости света).
Отсюда следует вывод, что гораздо выгодней до скорости света разгонять не фулстека, а, например, корову, тем самым получая источник пищи с массой стремящейся к бесконечности.
Отсюда следует вывод, что гораздо выгодней до скорости света разгонять не фулстека
Не-не, фулстека разгонять не нужно, нужно заказчика, для него время замедляется. А фулстекер тем временем батрачит на дядю, для заказчика прошло пару дней, а фулстекер уже состарился, умер и разложился.
«При скорости движения близкой к скорости света» если на объект действует некоторая сила, то масса (m) объекта стремится к бесконечности (F = m * a), в силу того, что ускорение (a) стремится к 0 (т.к. объект не может двигаться быстрее скорости света).
* з силою в релятивістській фізиці не все так просто, як мінімум F = (m * a) в загальному випадку невірно;
* щодо прямування прискорення до нуля, то це залежить від системи координат, в якій Ви вимірюєте, — в різних воно може виглядати дуже по різному;
* ну і з приводу зростання маси... більшість сучасних робіт по фізиці старається так не писати. так само стараються більше не вживати понять «релятивістська маса» та «маса спокою», бо вони заплутують. натомість кажуть по-простому «маса» і означають її як довжину
и в итоге мы успеваем сделать в кратно раз
Мне кажется, именно это в Skyeng и попытались сделать :) У них, во всяком случае как они говорят, более-менее получилось. Может, применимо и в других случаях, хотелось бы понять, в каких. Обычно за высокую скорость имптементации фич надо будет заплатить чем-то другим и, возможно, иногда это приемлимая цена.
У них, во всяком случае как они говорят, более-менее получилось.
Однажды цыган решил отучить свою лошадь есть. Прошла пара недель, и
лошадь отвыкла кушать. Но потом почему-то умерла...
Владимир Кожаев
Mike Gorchak
Beaver Green
Андрей Губский
Lyova Zi
Vadim Kuznetsov
Vadym Liapin
anonymous
Андрей Литвинов
Dmitry
Мокий Парменыч
Олексій Пєніє
John Appleseed
Mike Gorchak
Котэ
Конь в Пальто
Владимир Кожаев
Андрей Губский
Jaroslav Shkarupilo
John Appleseed
Gennady Dogaev
Jaroslav Shkarupilo
Gremlin
Dmitry Bugay
anonymus ps
Дима Дима
Not Sure
Котэ
Dmitry Bugay
Vitaly Chernooky
Дмитро Сафронов
Oleksii Samokhvalov
Bot Bot
Александр Шевченко
Михаил Сидоренко
Lyova Zi
Oleksandr Merkulov
Александр Липских
Vitaliy Marenkov
Андрей Литвинов
Max Shnurenok
Ювженко Денис
Мокий Парменыч
Gremlin
fj
Dmitriy Luganskiy
Artem Perchyk
De Money
Найкращі коментарі пропустити