Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Вот тебе задача на час или на два. Ты можешь её делать, как считаешь нужным. Вот наши критерии завершённости, вот тебе инструменты
Почему вы своим программистам так не доверяете?
Задача на час или на два это строк 30 в проде. Фантазии и свободы просто вагон.
А второй способ называется «за результат»
Основная проблема — для проверки результата нужен высокий уровень технической компетентности, а у большинства управленцев его просто нет. Т.е. обычно для управления используют знания из психологии, практики общения и т.д., по этому нужен физический контакт, ибо оценить результат весьма не просто.
Только те, кто много и качественно работает. Они могут зарабатывать очень много. Верхней границы нет и быть не может.
Вот тут манипуляция и уход от вопроса.
Если так говорить, то и возможности заработка строителя или грузчика — тоже ничем не ограничены, ведь если за тонну разгрузки платят, скажем, 2000 руб, то что мешает тебе за день разгружать по 2 мегатонны и заработывать миллионы в день?
Но это обман и манипуляция.
Есть пределы человеческих возможностей и все мы прекрасно понимаем, что скорость работы разных людей хоть и отличается, но все же область не так уж широка.
Хотелось бы узнать максимальную зарплату за год (именно за год, т.к. чел. мог работать быстро один месяц и потом выгореть), среднюю зарплату за год и минимальную.
А так же как вы оцениваете результат работы. Могли бы вы привести решение одной из задач, т.е. код, и указать сколько за него денег чел. получил?
Если брать чисто скорость написания кода — возможно и не большой разбег.
А вот если с учетом долгосрочного проекта и набегающего увеличения сложности, связности кода и багов, то тут переделки в какой-то момент могут сожрать 90% продуктивности и плохой прогер от хорошего может отличаться и в 8-10 раз.
А вот если с учетом долгосрочного проекта и набегающего увеличения сложности, связности кода и багов, то тут переделки в какой-то момент могут сожрать 90% продуктивности и плохой прогер от хорошего может отличаться и в 8-10 раз.
переделки в какой-то момент могут сожрать 90% продуктивности и плохой прогер от хорошего может отличаться и в 8-10 раз.
Это не то что хороший/плохой, это разные специализации. И разница может быть не в 8-10 раз, а на 3 порядка. То же самое, кстати, актуально и для строителей — есть разные специализации. Как то если чел. занимается только сантехникой, у него построен процесс, есть современные инструменты, работает с лучшими материалами. Он будет работать на порядок быстрее и качественнее чем тот, кто «на все руки мастер». Второй тоже сможет, конечно, но займет и дольше и качество будет хуже.
Если область сложная, как то реализация крипто-алгоритма по спецификации, то спец. выполнит на 3 порядка быстрее, т.к. не работающему в данной предметной области придется сначала вникнуть, что займет уйму времени.
Вот-вот.
А вообще мне кажется это не масштабируемый вариант. Есть автор поста, и он скажем вполне адекватно может оценить время/стоимость задачи. И при этом готов нормально ее оплатить. В этом случае система работает.
Но как только нам нужно будет увеличить группу в 10 раз, окажется что нужно еще минимум 4-5 человек которые будут помимо автора это делать, и тут человеческий фактор скорее всего сломает систему — или денег пожадничают, или с оценкой трудозатрат ошибутся, и в результате хорошие прогеры быстро разбегутся, а плохие останутся и окончательно избалуются, рисуя липовые часы, либо текучка начнется.
Мне больше интересны принципы, которые от личности руководителя не особо зависят.
А вообще мне кажется это не масштабируемый вариант. Есть автор поста, и он скажем вполне адекватно может оценить время/стоимость задачи. И при этом готов нормально ее оплатить. В этом случае система работает.
Но как только нам нужно будет увеличить группу в 10 раз, окажется что нужно еще минимум 4-5 человек которые будут помимо автора это делать, и тут человеческий фактор скорее всего сломает систему — или денег пожадничают, или с оценкой трудозатрат ошибутся, и в результате хорошие прогеры быстро разбегутся, а плохие останутся и окончательно избалуются, рисуя липовые часы, либо текучка начнется.
Мне больше интересны принципы, которые от личности руководителя не особо зависят.
Вот-вот.
Это умение правильно подобрать спеца под задачу. Но ведь под каждую задачу не будешь искать отдельного спеца… Даже если задачу А первый спец. выполнит на порядок-два быстрее второго, то может забуксовать на задаче Б, которую уже второй выполнит быстрее. Ведь опыт у всех разный, а когда что-то выполняешь во второй раз, с чем то уже сталкивался — то, понятное дело, времени займет меньше.
Интервью, по ощущениям, очень похоже на пресс конференцию солнцеликого — в каждом вопросе интервьера либо уже ответ либо не сильно скрытое восхищение. Поэтому и не было неудобных вопросов. Поэтому и неинтересно получилось.
И даже в таки условиях много "интересного" вылезло:
- "Через два часа он приносит и говорит: «Вот мой результат». Или говорит: «Такое сделать за два часа никак нельзя, и вот почему. Я придумал вот такое решение на будущее»." — вроде бы всё хорошо, да? А оплата-то будет, или "ничего не сделал, ничего не заработал"?
- "И они за месяц могут не заработать ничего." — т.е. ни отпусков, ни больничных? А давайте тогда из средней зарплаты вычтем как минимум 15%.
- "Зачем нам конкурировать, например, с московскими компаниями, кто может себе позволить платить много денег за сильного разработчика, когда наши ресурсы скромнее?" — про 15% помним? Так ещё и без их учёта сумма получается меньше!.. Не, ну а что, индусы же с китайцам всё равно сделают?!
- "Важно понимать, мы не перепродаем время дешевых разработчиков за дорого, как все обычно делают." — а вот тут вообще непонятно… если вы берёте разработчиков и продаёте их время за деньги клиентам, то вы именно этим и занимаетесь. Вот не увидел я в этом интервью продуктовую компанию. От слова совсем. А вот и продолжение "А еще у нас немножко другие ценники. Они выше рыночных по России в несколько раз." — ну как и ожидалось, берём сотрудников по одной ставке, продаём по совсем другой… а уже если посмотреть ещё и на предыдущий пункт — так у барина-то и на масло и на икорку к бутерброду денег найдётся.
- "Когда ты смотришь на какой-то класс, ты уже видишь, что это не просто класс, а это класс, который отвечает за определенную область бизнеса – «а, вот оно что!»" — и что, долой унификацию? (с ней, конечно, тоже надо быть осторожным, но общие методы они потому и общие, что куча бизнес-задач выполняется по похожим правилам)
- "И второй момент – документация. Хорошая документация может быть написана только тогда, когда она нужна. Потому что, если её пишут из-под палки и в неё не смотрят, не обновляют, она быстро становится плохой. Хорошая документация, например, в опенсорс-проектах как пишется? Она единственный источник того, как люди могут про этот опенсорс-проект узнать и воспользоваться." — хорошая документация, это минимум х2 прайс заказчику. Сэкономили на программистах, отыгрались на аналитиках. И я не против документации (я даже за неё… мне, как разработчику, намного легче писать код, если документация в хорошем состоянии), но это действительно отдельный финансовый потребитель в проектах. А уж про документацию в опенсорцах — лучше не надо. Действительно есть проекты, где документация хорошая… Но у них или есть отличные фонды или прямые спонсоры. Документация в ОСП без хороших спосноров в лучшем случае есть. В худшем такая — что лучше бы чтобы её не было.
- "Разработчик создаёт задачку, говорит: «У меня что-то не работает», либо «Я не понимаю документацию», либо «Я хочу новую фичу». Ты смотришь, что нужно сделать для того, чтобы его удовлетворить." — опять какие-то голубые фантазии. В большинстве случаев разработчик допиливает функционал ОСП под себя. Ну а то, что это будет полезно кому-то ещё — ну дак и хорошо.
- "Мне пришлось всех, кто у нас тот момент был, уволить и по сути начать заново." — очень надёжный работодатель… прям пятки горят, как бегу к такому. Ведь он в любой момент может снова "Я просто рубанул и начал заново.", а ты сиди, соси лапу.
«Мы набираем готовых работать за еду, поэтому у нас нет проблем с программистами и в этом наш успех».
+
«Хорошая организация труда и оплаты и, как следствие, минимальные деньги программистам с максимальным выхлопом».
Хорошая схема для проекта, но не очень — для желающих в нём поработать.
Особенно смутили намёки про то что люди часто меняются (и архитектура проекта под это заточена) и отношение как к коллективу, а не команде — очень и очень нехороший маркер для работников. Звучит как «выжимать из тех кто пришёл максимум, а потом выбрасывать, потому что есть ещё легион на замену».
Эффективный менеджмент как он есть.
Так же, про декомпозицию на маленькие задачи (2 часа?!). Когда проект большой и задачи сложные, то для управления и развития требуются специалисты, которым быстрее реализовать задачу «на два часа кому то там», чем даже написать эту задачу. Совсем другой масштаб. И такое не отдашь тому, кто не погружён или просто по документации.
Я, всё-таки, за то, что бы проект делался командой. Удалённой или нет — не важно. Особенно проект требующий глубокого погружения — люди создают большую логику и понимают как она в целом и по частям будет работать, и делигировать части этой логики — большой риск. Да и специалисты которые это делают — стоят дорого…
Как то так.
+
«Хорошая организация труда и оплаты и, как следствие, минимальные деньги программистам с максимальным выхлопом».
Хорошая схема для проекта, но не очень — для желающих в нём поработать.
Особенно смутили намёки про то что люди часто меняются (и архитектура проекта под это заточена) и отношение как к коллективу, а не команде — очень и очень нехороший маркер для работников. Звучит как «выжимать из тех кто пришёл максимум, а потом выбрасывать, потому что есть ещё легион на замену».
Эффективный менеджмент как он есть.
Так же, про декомпозицию на маленькие задачи (2 часа?!). Когда проект большой и задачи сложные, то для управления и развития требуются специалисты, которым быстрее реализовать задачу «на два часа кому то там», чем даже написать эту задачу. Совсем другой масштаб. И такое не отдашь тому, кто не погружён или просто по документации.
Я, всё-таки, за то, что бы проект делался командой. Удалённой или нет — не важно. Особенно проект требующий глубокого погружения — люди создают большую логику и понимают как она в целом и по частям будет работать, и делигировать части этой логики — большой риск. Да и специалисты которые это делают — стоят дорого…
Как то так.
Ну, требование писать документацию так чтобы без присутствия тебя лично с нею разобрался бы любой- это вполне здоровое требование, причем характерное и для других сфер, например от нас так требовали вести замеры в лабораториях. Просто потому что через месяц ты уже сам не вспомнишь, что тут накалякал.
Это просто обеспечивает высокое качество кода и документации.
Это просто обеспечивает высокое качество кода и документации.
кто по полгода не может найти себе разработчика
Ну это проблема именно в этих «кто-то». Ситуация на рынке IT как в индийском поезде, кодерков выше крыши, бери — не хочу. И это миддлы и выше. Посему тут проблема очень проста, сформулирую.
Галера не хочет платить хорошую зп хорошему разработчику, жмотится и старается дать поменьше. Как альтернатива — выдвигает за нормальную зп неадекватные требования, возможно, ищет супер-пупер фуллстэка (чтобы не платить двум узким спецам). Ищет сеньора на мидловскую позицию, при этом не желает вырастить из крепкого разработчика уровня middle+ хорошего сеньора за год-другой. Чаще всего таким грешат непродуктовые конторки (это и понятно), но, к сожалению, и в продуктовых эти грешки сплошь и рядом.
Так что делайте выводы, господа. А найти хорошего разработчика middle \ middle+ не проблема за 1-2 недели.
Судя по тексту, это получается какой-то фрилансерский подход, когда у тебя есть задача и тебе за нее платят, а уж каким образом и сколько ты ее будешь ковырять сугубо твои проблемы.
Не напрягает ли сотрудников такой подход? Многие ищут постоянную работу как раз ради стабильности, а тут стабильности то и нет: можешь заработать горы, упахиваясь в ноль, а можешь остаться ни с чем? Какое тогда отличия работы с вами от фриланса с точки зрения сотрудника?
Не напрягает ли сотрудников такой подход? Многие ищут постоянную работу как раз ради стабильности, а тут стабильности то и нет: можешь заработать горы, упахиваясь в ноль, а можешь остаться ни с чем? Какое тогда отличия работы с вами от фриланса с точки зрения сотрудника?
Вот-вот у меня к масштабируемости тоже очень большие вопросы. Такое держится на одном человеке, и когда надо расширится за пределы того обьема, который данный человек может вытянуть — нанятый второй запросто пускает систему под откос.
А как бы так выстроить требования, чтобы хорошо получалось в любом случае, с или без талантливых лидов — очень интересный вопрос. Когда-то Форд поставил производство авто на конвейер, где бы найти способ штамповать кадры…
А как бы так выстроить требования, чтобы хорошо получалось в любом случае, с или без талантливых лидов — очень интересный вопрос. Когда-то Форд поставил производство авто на конвейер, где бы найти способ штамповать кадры…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распределенно ДА или распределенно НЕТ? Интервью для тех, кто по полгода не может найти себе разработчика