Comments 51
Прочитал статью, озвученные проблемы имеют место, но решение как по мне очень спорное.
При таком подходе возникают следующие вопросы — кто оценивает время выполнения задачи (ну или её цену). Что делать, если сложность задачи недооценили, как оценивать задачи на проектирование или на исследование проблемы. Как ставится задача когда есть проблема (бага) но она плавающая/сложно воспроизводится/непонятно откуда «ноги растут». Кто-то же должен локализовать проблему и разобраться, при этом время оценить в принципе нельзя, только по факту. Что делать если никто не берёт какую-то задачу потому что не хотят?
Так же вопрос, кто проверяет проверяющих и так до бесконечности. Возможность проверки код-ревью означает, что есть специалист более высокого уровня, который по сути и станет неформальным начальником. Или я не прав?
В общем такое ощущение, что данный подход работает только при аутсорсе, при этом компания представляет собой всего-лишь ещё одну биржу, и смысл работы в ней непонятен.
Я могу быть не прав, тогда поправьте меня)
При таком подходе возникают следующие вопросы — кто оценивает время выполнения задачи (ну или её цену). Что делать, если сложность задачи недооценили, как оценивать задачи на проектирование или на исследование проблемы. Как ставится задача когда есть проблема (бага) но она плавающая/сложно воспроизводится/непонятно откуда «ноги растут». Кто-то же должен локализовать проблему и разобраться, при этом время оценить в принципе нельзя, только по факту. Что делать если никто не берёт какую-то задачу потому что не хотят?
Так же вопрос, кто проверяет проверяющих и так до бесконечности. Возможность проверки код-ревью означает, что есть специалист более высокого уровня, который по сути и станет неформальным начальником. Или я не прав?
В общем такое ощущение, что данный подход работает только при аутсорсе, при этом компания представляет собой всего-лишь ещё одну биржу, и смысл работы в ней непонятен.
Я могу быть не прав, тогда поправьте меня)
>В общем такое ощущение, что данный подход работает только при аутсорсе, при этом компания представляет собой всего-лишь ещё одну биржу, и смысл работы в ней непонятен.
Очень хорошо сформулировано. Да, компания которую наверное лучше обходить стороной )
Очень хорошо сформулировано. Да, компания которую наверное лучше обходить стороной )
«А судьи кто?»
*upd. простите ответил сразу не на тот комменатрий
судьи — опытные разработики которые будут голосовать ногами
судьи — опытные разработики которые будут голосовать ногами
Я работал фрилансером, с почасовой и оплатой за проект. Так вот с оплатой за проект было трудно и невыгодно, т.к. всегда возникают задачи, которые ты не ожидал. Договорились что за 6 месяцев поставлю систему, в итоге работал 12, реально последние 2 месяца работал себе в убыток, лишь бы закончить проект.
мне кажется что многим инженерам будет претить торговаться за каждую задачу, ощущение как на рынке в Индии. Поэтому на fix price наверное можно соглашаться только от безысходности, и всегда радуешься когда вырастаешь из этих штанишек.
Только хорошая почасавая оплата, желательно с людьми которые говорят на английском без сильно выраженного русского акцента.
Только хорошая почасавая оплата, желательно с людьми которые говорят на английском без сильно выраженного русского акцента.
>Мы общаемся только на рабочие темы. Если кто-то хочет обсудить «Игру престолов» — извини, мы работаем, а «Игру престолов» обсуждай со своими друзьями. Если хочешь обсудить новую технологию, создай тикет, давай ее обсудим: возможно, она принесет пользу проекту. Но «Игра престолов» точно не принесет пользы проекту.
>Оплата за результат. Это самая холиварная часть: мы не платим зарплаты. Кто-то пошутил, что мы не платим разработчикам в принципе.
жесть
>Оплата за результат. Это самая холиварная часть: мы не платим зарплаты. Кто-то пошутил, что мы не платим разработчикам в принципе.
жесть
Игра престолов или оплата за результат?
и то и то.
В книге «Remote. Офис не обязателен» авторы наоборот говорили о необходимости неформального общения, мол этот «water cooler» где обмениваться анекдотами и фильмами, тут же тезис о том что все должно быть жёстко про бизнес не совсем раскрыт, мне кажется это не будет работать в долгосрочной перспективе.
Тоже самое с оплатой за результат, люди уйдут как только смогут найти что-то получше.
В книге «Remote. Офис не обязателен» авторы наоборот говорили о необходимости неформального общения, мол этот «water cooler» где обмениваться анекдотами и фильмами, тут же тезис о том что все должно быть жёстко про бизнес не совсем раскрыт, мне кажется это не будет работать в долгосрочной перспективе.
Тоже самое с оплатой за результат, люди уйдут как только смогут найти что-то получше.
Оплата за результат у меня всегда асоциируется с сетевым маркеттингом аля орифлейм.
не хватает примера задачи с оценкой
Спасибо за полезную статью. Хотя многое в ней завязано на удаленную работу, как я понял, какие-то процессы можно применить и к работе в офисе — грамотная постановка задач, кодревью, линтеры. Насчет общения на нерабочие темы — для этого есть короткие перерывы на кухне, к примеру. Там никто никого не вырывает из потока. Насчет митингов — согласен целиком и полностью. Поэтому, если и проводить их, то а) быть подготовленным б) делать их короткими и по выделенной тематике с) в соответствии с предыдущим пунктом, звать только необходимых людей. Как-то так.
Мммм, механистический подход к труду, прямо как сто лет назад.
Работать точно будет, даже достаточно эффективно. Одна беда, люди, которые могут найти более человечное место, уйдут очень быстро. Останутся либо те, кто не сможет найти, либо те немногие, кому действительно совсем не нужно общение на работе.
Для простых задач не критично, конечно, но что-то действительно интересное в такой обстановке, мне кажется, не создать. Просто слишком жесть. Вот избавиться бы от абсолютизма, сделать поправку на то что люди не машины, и как все лучше было бы.
Работать точно будет, даже достаточно эффективно. Одна беда, люди, которые могут найти более человечное место, уйдут очень быстро. Останутся либо те, кто не сможет найти, либо те немногие, кому действительно совсем не нужно общение на работе.
Для простых задач не критично, конечно, но что-то действительно интересное в такой обстановке, мне кажется, не создать. Просто слишком жесть. Вот избавиться бы от абсолютизма, сделать поправку на то что люди не машины, и как все лучше было бы.
В скором будущем так и будет, но вместо людей будут роботы. Вполне возможно типовые задачи систематизировать и создать таких роботов.
Гм, с другой стороны… работа без приседаний, где я честно продаю свое время за деньги, а не притворяюсь, что мне нравится лайкать уродливые фотки новорожденных в #general.
А «цену» тикета кто определяет? Разработчик может отказаться от задачи, если не согласен с её ценой?
Может быть, я морально не готов к этой прорывной идее или неправильно понял посыл статьи — но это все звучит как описание очередной галеры с небезызвестного сайта на домене .it — и менеджер-евангелист, который, разумеется, может писать код сутки напролёт, и невероятный контроль на рабочем месте (про игру престолов нельзя говорить, линтер пишет код за тебя, потому что менеджер для себя решил что никто не умеет писать код [как ему нравится]), неопределенная зарплата по тайным kpi.
Может быть, я морально не готов к этой прорывной идее или неправильно понял посыл статьи — но это все звучит как описание очередной галеры с небезызвестного сайта на домене .it — и менеджер-евангелист, который, разумеется, может писать код сутки напролёт, и невероятный контроль на рабочем месте (про игру престолов нельзя говорить, линтер пишет код за тебя, потому что менеджер для себя решил что никто не умеет писать код [как ему нравится]), неопределенная зарплата по тайным kpi.
Мы понимаем, что разработчики могут исчезнуть, не хотеть работать и не работать, у них может быть плохое настроение, им нужна полная свобода.
Я не очень понял, как обрабатывается случай, когда человек подписался на выполнение задачи и потом исчез. У задачи же есть определенный срок — договоренность с заказчиком, что задача будет выполнена к определенному времени. И что делать с такой «подвисшей» на конкретном сотруднике задачей?
Шикарно, почти идеально, с оплатой только не очень понятно, как например оценивается сделал ревью человек или нет?
UFO just landed and posted this here
А это точно не статья Егора Бугаенко? Как-то очень много общих тезисов.
Если у вас все(ну или большая часть) народа это фрилансеры на удалёнке, то это может быть и имеет смысл так работать. Но для более-менее нормальной фирмы это какая-то адская жесть. Я бы так точно работать не cтал и не факт что вообще бы смог.
Например я считаю хорошая команда это как раз таки один из больших плюсов для фирмы в целом и для меня лично. И хорошая команда это в моём понимании как раз таки в том числе и возможнотсь сделать паузу, взять кофе и пять-десять минут пообсуждать какие-то нерабочие темы вроде «Игры престолов». И на мой взгляд работа от этого совсем не страдает, а скорее наоборот.
Например я считаю хорошая команда это как раз таки один из больших плюсов для фирмы в целом и для меня лично. И хорошая команда это в моём понимании как раз таки в том числе и возможнотсь сделать паузу, взять кофе и пять-десять минут пообсуждать какие-то нерабочие темы вроде «Игры престолов». И на мой взгляд работа от этого совсем не страдает, а скорее наоборот.
А меня люто бесит сочетание этого проклятого новомодного опенспейса и общительных коллег, которые перекрикиваются из одного угла опенспеса в другой, или как раз в том момент когда тебе надо сосредоточится начинают шумно обсуждать очередную игру престолов.
В этом мне описанный подход нравится. Пришел на работу — работай, хочешь общаться — общайся где-то на стороне.
По тексту — есть хорошие идеи, и в идеально настроенном подобном окружении наверное хорошо работать. Но вот только смущают несколько моментов.
В этом мне описанный подход нравится. Пришел на работу — работай, хочешь общаться — общайся где-то на стороне.
По тексту — есть хорошие идеи, и в идеально настроенном подобном окружении наверное хорошо работать. Но вот только смущают несколько моментов.
- Кто ставит задачи, как это оплачивается (это ведь тоже работа, очень важная и не простая).
- Что делать если задача оценена неверно? Очень часто случается так, что какая-то простая на первый взгляд задача выливается в лютый адище для разработчика. А ее уже оценили в какие-то копейки, и исполнитель приступив к работе внезапно понимает что все эти потраченное на работу время и силы будут очень дешево оценены.
- Как быть с людьми, которые взялись за сложную и блокирующую множество других задачу, и задинамивших всю работу. Сначала просто отделывающихся фиктивными рапортами о работе, а потом и вовсе исчезнувших с радаров?
- И, еще раз — какой алгоритм оценки задач? При постоянной з/п этот вопрос не сильно критичный, ну ошиблись там, задача оказалась сложнее чем ее первоначально оценили, провозился с ней человек вместо запланированного дня, целую неделю. (Примем за данность то что человек добросовестный и специально резину не тянет, задача действительно оказалась непростой). На окладе ничего страшного не случилось, разработчик получит свою з/п и не будет сильно переживать, а как быть при такой сдельной работе?
По идее должны быть какие-то механизмы переоценки задач постфактум, иначе все разработчики начнут ради снижения риска брать исключительно тривиальные задачи, а все важные но более сложные навечно зависнут в беклоге
А меня люто бесит сочетание этого проклятого новомодного опенспейса и общительных коллег, которые перекрикиваются из одного угла опенспеса в другой, или как раз в том момент когда тебе надо сосредоточится начинают шумно обсуждать очередную игру престолов.
Хм, а кто сказал что надо обязательно из одной крайности бросаться в другую? У нас например комната на 6 человек и пообщаться на нерабочие темы мы обычно выходим на кухню :)
Увы, это не такая уж крайность. Все последние места в которых работал были с опенспейсом и коллегами которые никуда не выходили пообщаться. (Да если прямо попросишь не шуметь, какое-то время это работает, но недолго, а постоянно ругаться тоже не вариант, по множеству причин)
Я один раз в своей жизни работал в опенспэйс и мне пришлось купить себе хорошие наушники с активным шумоподавлением. И сидеть в них всё время, даже если я не слушал музыку.
К счастью страдал не только я и в какой-то момент начальство восприняло жалобы всерьёз. И опенспэйс разбили на комнаты.
Так что либо давить на начальство, либо менять работу, либо покупать наушники :)
К счастью страдал не только я и в какой-то момент начальство восприняло жалобы всерьёз. И опенспэйс разбили на комнаты.
Так что либо давить на начальство, либо менять работу, либо покупать наушники :)
Не исключаю, что все держится на гениальных пмах, которые продают заказчику задачу за миллион, а потом делят на пять разработчиков по рублю каждому.
UFO just landed and posted this here
> Мы научились записывать требования в специальном формате и формировать документацию.
Сколько лет формам IDEF? Сколько лет ARIS? Сколько лет UML? И вот ещё кто-то сделал для себя открытие — требования можно формализовать! Давайте придумаем, как это делать!
Сколько лет формам IDEF? Сколько лет ARIS? Сколько лет UML? И вот ещё кто-то сделал для себя открытие — требования можно формализовать! Давайте придумаем, как это делать!
Чтобы структурировать общение, достаточно сделать два шага:
- Зайти в Telegram прямо сейчас и удалить его. Как только ты удалишь все свои страницы в социальных сетях, люди не смогут тебе написать.
- После этого завести один канал и сказать, что с тобой можно общаться только так.
Это гениально! :)
UFO just landed and posted this here
У меня похожий жизненный опыт, поэтому я согласен с автором на 95%.
А бы в постановку задачи добавил еще один пункт из своей практики: задача должна быть проверяема. У меня был интересный опыт, нужно было расширить фреймворк, одной удобной фичей. Я написал фича-реквест, и приложил к нему тест которому должна была бы удовлетворять реализация. Но это не обязательно должны быть формальные критерии, это могут быть критерии описаные словесно. Список критериев. Тогда вероятность, что сделают не то и не так снижается значительно и задача выполняется быстрее.
UFO just landed and posted this here
Ни разу не встречал проектов с "нормальными" условиями.
UFO just landed and posted this here
Ну и лайфхак — мерить людей вокруг себя не идеальной линейкой, а той которой себя меряешь. А то себе можно и послабление, и уголок срезать и на хабре посидеть
Тут есть проблема — может оказаться, что себя человек меряет куда более суровой линейкой, чем казалось. Очень суровой линейкой. Вплоть до «ошибки недопустимы» линейкой. Один из вариантов проявления перфекционизма, он же одна из возможных причин.
Не совсем в тему. Но периодически одна мысль приходит по поводу «хорошего кода». А всегда ли он в принципе возможен? Как-то стараешься, ищешь, придумываешь, в общем идёшь к невидимой цели, тратишь силы. А она вообще существует, эта цель? В простых случаях существует. В сложных — возможно в принципе невозможно сделать идеальный код? Может быть, в большей или меньшей степени, сложный код всегда будет нагромождением странных конструкций?
Теоретической базы под это наверное нет.
Но взять, для примера, математику. В простых случаях всё просто и красиво 2+2=4. А чем дальше в лес… Тем всё малопонятнее и малопонятнее.
Теоретической базы под это наверное нет.
Но взять, для примера, математику. В простых случаях всё просто и красиво 2+2=4. А чем дальше в лес… Тем всё малопонятнее и малопонятнее.
Тут как в школе, ты может задачу и решил, однако у тебя, мол, поля в тетради не расчерчены, слово «ответ» не выделено, и промежуточные шаги не обозначены, поэтому четыре с минусом. А так ты можешь быть хоть Альбертом Германовичем Эйнштейном, всем пофиг.
Но! Это только с одной стороны, мы пытаемся придерживаться норм и правил, которые якобы на решение не влияют. Как бы! Однако, надо понимать, что эти нормы и правила придуманы не просто так. Они помогают предотвращать затруднения. Вот в примере выше, хорошо оформленный ответ, помогает другим читать и понимать его. На каменных стенах в дальних странах могут быть написаны все секреты мироздания, но если мы их не можем прочитать, расшифровать, осмыслить, то они ничего не стоят, к сожалению.
А цели действительно как таковой нет, можно придерживаться разных стандартов. Как в школах разных стран ответы оформляют по разному. И задачи решают по разному. И считают по разному. Немцы например когда дают сдачу они прибавляют к сумме пока не получится купюра которую ты дал. И ведь нормально живут. Кассиру так быстрее. И меньше вероятности ошибиться. Поэтому его научили так.
Подытоживая, скажу так: не надо париться, но нельзя не париться вообще.
Нужно соотносить сообразность всей «оформительской работы» с поставленной задачей. Из практики могу сказать, опытный тимлид видет в этом смысл (потому что у него взгляд другой, ему нужен хороший код, на этот код могут ведь потом и других ребят посадить). А рядовой разроботчик не видит этого, у него другая перспектива: надо выполнить задачу. Работает, значит выполнил. «Че пристал. Я решил». Они могут не видить контекста. Т.е если ты решаешь задачи для себя — делай как хочешь. Но если ты хочешь как-то взаимодействовать с окружающим миром, будь добр, соответствовать стандартам.
Идеального кода, конечно, не существует, и не может существовать, потому что код всего лишь средство выражения мысли. Все что я сказал можно написать совсем другими словами, и кто-то скажет что стилистика стала лучше. Кто-то посчитает что это вообще не относится к делу, и поставит минус. Люди оценивают нашу работу. Нужно делать так, чтобы большинству она нравилась. Так что не надо париться, но нельзя не париться вообще.
Но! Это только с одной стороны, мы пытаемся придерживаться норм и правил, которые якобы на решение не влияют. Как бы! Однако, надо понимать, что эти нормы и правила придуманы не просто так. Они помогают предотвращать затруднения. Вот в примере выше, хорошо оформленный ответ, помогает другим читать и понимать его. На каменных стенах в дальних странах могут быть написаны все секреты мироздания, но если мы их не можем прочитать, расшифровать, осмыслить, то они ничего не стоят, к сожалению.
А цели действительно как таковой нет, можно придерживаться разных стандартов. Как в школах разных стран ответы оформляют по разному. И задачи решают по разному. И считают по разному. Немцы например когда дают сдачу они прибавляют к сумме пока не получится купюра которую ты дал. И ведь нормально живут. Кассиру так быстрее. И меньше вероятности ошибиться. Поэтому его научили так.
Подытоживая, скажу так: не надо париться, но нельзя не париться вообще.
Нужно соотносить сообразность всей «оформительской работы» с поставленной задачей. Из практики могу сказать, опытный тимлид видет в этом смысл (потому что у него взгляд другой, ему нужен хороший код, на этот код могут ведь потом и других ребят посадить). А рядовой разроботчик не видит этого, у него другая перспектива: надо выполнить задачу. Работает, значит выполнил. «Че пристал. Я решил». Они могут не видить контекста. Т.е если ты решаешь задачи для себя — делай как хочешь. Но если ты хочешь как-то взаимодействовать с окружающим миром, будь добр, соответствовать стандартам.
Идеального кода, конечно, не существует, и не может существовать, потому что код всего лишь средство выражения мысли. Все что я сказал можно написать совсем другими словами, и кто-то скажет что стилистика стала лучше. Кто-то посчитает что это вообще не относится к делу, и поставит минус. Люди оценивают нашу работу. Нужно делать так, чтобы большинству она нравилась. Так что не надо париться, но нельзя не париться вообще.
UFO just landed and posted this here
Ещё с линтером момент — они тупые обычно и при закручивании гайк придётся не работу делать, а линтер удовлетворять, поэтому было бы интересно услышать тех кто работал в этой системе по этому и другим вопросам.
Боюсь, что это всё про начало эксперимента (который провалится), а не про опыт успешной компании, которая прожила хотя бы лет 5.
Сюда бы самого Никиту в комментарии =)
Оплата за результат. Это самая холиварная часть: мы не платим зарплаты. Кто-то пошутил, что мы не платим разработчикам в принципе...— для галер и аутстаффа подход, может быть, и оправдан, но со стороны разработчика возникает острое чувство социальной незащищенности. Вот сломал коллега руку — все, будет кушать воду из-под крана?
Sign up to leave a comment.
Blameless environment: никто не должен писать качественный код