Pull to refresh

Comments 37

Основной стек, с помощью которого решаем задачи клиентов:
1. Java / Kotlin / Scala.
2. Angular 2 и выше, React.
3. Python.
4. QA Automation (Java и Python).
В доступе к лучшим кадрам. В возможности не привязываться к физическому месту работы. Это многие уже считают роскошью 21 века. Мы ценим эту свободу, которая, безусловно, требует повышенной ответственности.
Плюс 3-4 часа ежедневно на дорогу в условиях Москвы и ближнего Подмосковья явно не добавляет производительности программисту.
Появляется возможность подключать к работе талантливых исполнителей из других регионов за меньше деньги
восемь часов действительно работает
Это очень общее понятие. Что именно это значит для вас?

Когда работаешь в офисе, то 8 часов — это время нахождения в офисе. Максимум дня два в неделю удается покодить 6 часов в день. В обычный день, в среднем 4 — 5 часов кодишь или разбираешься. Остальное время тратится на не понятно что — на поболтать, чай, кофе, отдохнуть.
И это, по моему мнению, нормально, человек не выдержит длительно более интенсивных нагрузок.
Когда читаешь спеки или доки по библиотекам то 80% времени ты читаешь, а не кодишь.
Как вы проверите на что ушло время?
Или когда общаешься с сотрудниками / заказчиком, то вообще за три дня не пишешь и строчки кода.

У меня на удаленке получается что 7 (без обеда) часов я отрабатываю за 11 часов реального времени (с обедом 1 час). То есть по помодоро 7 часов чистого времени, без учета времени перерывов — а астрономическое 11 часов. Это норм? А как вы учитываете или требуете часы?
человек не выдержит длительно более интенсивных нагрузок
На самом деле выдержит, но недолго, я помню первые полгода-год работы своей 8 часов работал (именно код писал, хотя скорее пытался))), плюс после работы часа по 2-3 изучал платформу, плюс на выходных старался хотя бы часов по 5 когда работать когда учиться. В итоге заработал нервный тик и еженедельные головные боли, но освоился со временем. А нервный тик быстро прошел, за несколько месяцев после выхода из такого режима. Спустя пару лет и голова теперь болит гораздо реже, раз-два в месяц.
Сейчас у меня режим такой: 4-5 часов на работе стараюсь именно код писать, ТЗ, ТП и подобное, остальное чай, печеньки, совещания, чтение статей. + в дома час-два на продолжение изучения программирования в день, + опять же дома пол часа-час в день на японский язык. Правда подумываю его или чередовать с английским, либо английский сверху накинуть. А на выходных в основном отдыхаю. Часа 3-4, не больше, на учебу. Немного еще уточню, вообще обычно больше по времени непосредственно на работу уходило, часов по 7, но сейчас чуть расслабиться себе позволил. Еще немного подумав: интересно, а куда относить время когда например в душе над рабочими задачами думаешь или за завтраком?))
Хотя кто то может и дольше в более напряженном графике выдержать, от человека зависит.
На мой опыт больше чем 70% продуктивно использованного рабочего времени — это либо кратковременное состояние, либо утопия. Даже в близких к идеалу случаях (нет препятствий, совещаний, вопросов от коллег, и тэ дэ) — из восьми часов рабочего дня минимум час уходит на информационную логистику — почту прочитать, исходники обновить, и тому подобные мелочи. Второй час и более уходит на перерывы вида «встали и выдохнули», сидеть без движения приёмами свыше 3-4 часов мало кто может.

А уж если случай не идеальный — то будет еще больше вынужденных перерывов в работе, и не все из них попадут на твои собственные перерывы.

Итого да, вы всё правильно написали, из 8 часов покодить 6 — это максимум, и даже он далеко не всегда выходит.
Мы не требуем 8 часов непрерывного кодинга, если вы об этом. Рабочий процесс включает планирование, изучение новых технологий, code review для разработчиков и автоматизаторов тестирования и т.п. Все это закладывается на этапе оценки проекта.
Тоже посчитал — 3-4 часа в день именно на написание кода. Тому несколько причин:
1. Прежде чем писать — надо понять что именно надо написать. Придумать архитектуру решения, если речь не идет об узкой задаче. На это уходит много времени, в рамках проекта — до 30%.
2. Поняв что надо сделать — надо понять как это сделать. Есть, конечно, наработки, но всегда есть и альтернативы, всегда есть что-то свежее. В итоге, требуется написать прототип решения, иногда — несколько, чтобы оценить что выбрать. Если сроки сильно ограничены — делаю так, как наиболее знакомо, но при этом заказчик получит возможно не лучшее решение. Это еще 30% времени.
3. Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость. Производительность со временем падает, ничего хорошего не получается. Можно работать больше, если не прикладывать усилий для разбирательства в делаемом — то есть шпарить по шаблонам, но это опять же в ущерб возможностям и не всегда вообще это доступно в силу специфики задачи. — Это еще 30%

Еще 10 оставшихся процентов — это развертывания всего на свете, деплои, тесты и прочая.

Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа — итого шесть, еще около 2-3 часов отвожу на изучение платформ, инструментов, технологий, на эксперименты. Работая больше — ловлю себя на том, что острота мысли падает и в итоге работаешь отнюдь не лучше и продуктивнее, а совсем напротив.

У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить… Что тут сложного! На всякие раздумья и прочее их жаба смотрит осуждающее и с полным непониманием.
Тоже посчитал — 3-4 часа в день именно на написание кода.

Зависит от тренировки. Если начинал с самого детства, то лет за 10 можно и 6-8 часов в день выдерживать. Зависит еще сильно от общего физического состояния.
В 14 лет с трудом выжимал из себя 15-40 минут непрерывной концентрации на коде — поэтому везде ходил с блокнотом и карандашом — писал всякую хрень. К 30 годам 6 часов непрерывной умственной нагрузки — даже усталости нет.


Однако при приближении к 8 часам есть снижение всех когнитивных навыков, т.е. вообще всех, падает реакция, глаза болят и висок ноет (левый). По 7-8 часов в день больше 14 дней подряд не выдерживаю, нужен отдых. Силой никто не гонит, просто "хочется еще".


Если так весь год работать, то нужен отпуск примерно 48 дней.
Субъективно, согласен — но пища для размышлений есть.


Поняв что надо сделать — надо понять как это сделать

Так ведь уже сказали, что декомпозиция осуществлена. Все остальные операции — уже очень легкие и не требуют существенного труда.


Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость.

Описал выше. Тренировка и общая физическая подготовка. Стоит обратить внимание на ваше питание. Почитайте про то, как маленькие улучшения коммулятивно дают прирост в разы.


Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа

Такой же подход, отвлекаюсь на приготовление обеда и т.д. Отвлечение на другую деятельность лучше всего позволяет мозгу отдохнуть.


У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить…

"Многие" даже траншеи не копали. На прошлой работе начальник вполне легко мог отвлечь посреди задачи, или вовсе что-то обсуждать.
Это не проблема кодинга, а проблема воспитания людей и коммуникации между ними. Вы же не сможете в деталях объяснить быт и труд шахтера? Каждый человек живет в своем мире, просто у кого-то он размером с горошину — представления о других людях соответственные.

Мои 3-4 часа — это наиболее плодотворные часы, когда создается что-то новое в проекте, естественно, бывает и больше, но в среднем — примерно столько в день. Больше 4 часов такой активной работы по моим наблюдениям — это уже приглаживание кода, пробы, отладка и т.д., но никак не наращивание функционала проекта. Поэтому я свой день и делю на две половины — в первую у меня обычно творческий подъем, я с прошлого вечера наметил и обдумал что и как сделать — а с утра начинаю воплощать. Заряда и придумок хватает как раз где-то на 3-4 часа.

Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.

Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!

При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!

Вы уже сами описали, что смешали работу нескольких специальностей.
Я же описывал именно "возможность" напрягать мозги в одном направлении в течении долгого времени. По опыту — максимум возможностей — 8 часов, и то после тренировок. И кстати результаты совпадают с общественной практикой, люди вообще больше 8 часов в день не могут продуктивно работать над чем-то в течении всего года. Замечу, речь именно о среднесуточной нагрузке в течении года, а не "две недели 60 часов отработал, а потом неделю отдыхал".


Когда есть возможность смешивать работу — ревью, очистка, отладка и т.д. — это облегчение работы.


аналитика, менеджера, программиста, тестировщика и DevOps.
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!

Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Но в целом — да. У нас так хаят "неквалифицированную рабочую силу", что забывают насколько "заказчики" бывают недалеки и неквалифицированны вообще во всех сферах кроме "заплатить меньше, получить больше".

Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.


Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.

Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
А зачем у вас такой жесткий график 8/9-17/18 по Москве? Почему гибче не получается?
Получается. В индивидуальном порядке — в зависимости от деталей каждого проекта.
Диссонанс какой-то. Вы оцениваете «результат», но при этом строгий 8-ми часовой рабочий день. А если я результат могу за 5 часов предоставить?
Если сможете дать необходимый результат за 5 часов, то нас это устроит.
Мы предполагаем, что все заявленное время сотрудник занимается полезной работой… Команды постоянно взаимодействуют – при удаленном формате работы это даже важнее, чем в офисе. Незаметно «исчезнуть» из всего этого взаимодействия невозможно.


Не будь это ваш реальный бизнес, я бы счёл это очередной утопией хабрашкольника. Потому что сам программирую и вот эти ваши «контроли без контроля» выглядят как-то непонятно.

Для начала, как правильно заметили и другие комментаторы, никто не работает 8 часов. И даже четырёх. Забудьте ваши странные «рабочие часы» — это всё пережитки рабовладельческого строя. Хороший программист «топчет клавиши» 2 часа максимум. Остальное — размышлизмы над кодом, вялое чтение мусора под названием «документация к библиотеке», поиск бедолаг по конкретному затыку и периодические «ответы на важные письма» с каких-нибудь Фишек. И это нормально — это мозг, которым нельзя работать 100% дня.

Далее, само понятие «удалёнки» — для меня это не просто возможность не везти задницу в офис и не стоять в пробках — это ещё и ГИБКИЙ ГРАФИК. Гибкий — не в вашем стиле «предупреди, мы найдём решение», а именно что я решаю, когда мне удобнее работать. Я вообще могу днём поехать в магазин — мне что, опять как ребёнок отпрашиваться у мамки? А не устанете «находить решения»? :)) Собственно, в этом и весь смысл — иметь свободный график и делать работу в максимально производительные для себя часы! Например, у меня это после 13 и вплоть до 24. Ну и нафик вы мне нужны в 9, когда я даже третий сон не досмотрел? :) Есть задача — пишите в таски. Нужно совещание — планируйте за день и мы дружно скайпом соберёмся. Но сообщать о каждом чихе — вообще не упёрлось, тогда уж снимайте офис!

И вот это вот «исчезнуть из взаимодействия» — вы чем вообще занимаетесь — программируете или бесконечно совещаетесь?? Я вообще-то и ударить могу, если меня будут отвлекать каждые полчаса от программирования! Если я В ПОТОКЕ, меня отвлекать нельзя. Точка. Это знает любой мало-мальский менеджер проекта. Поэтому я должен и буду «впадать в нирвану», где я пишу код со скоростью мысли. Довольно странно выглядит ваш процесс, если в нём человека дёргают весь день! Может, вы чего-то недообъяснили?
В налаженном проекте «совещания» и нужны именно, что раз в неделю — остальное время ты решаешь задачу, пишешь, тестируешь — сугубо индивидуальная работа.

Короче, мне кажется, вы только играетесь в «удалёнку», почти ничем особо не отличающуюся от «очной» офисной мутотени — разве что за компом можно сидеть в пижаме. :) А я-то думал светлое будущее программистов ближе.
Плюсанул бы, но нет правов: ) Я в последние полтора года работаю на фрилансе. Точнее — на подряде, проектно и со свободным графиком — есть план с дедлайнами по этапам, а внутри этого периода я могу работать где и сколько угодно — моя задача принести в клювике к обозначенному сроку результат.

За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.

И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Если я В ПОТОКЕ, меня отвлекать нельзя. Точка.

Именно так. И от формата работы офис/дом это не зависит.
Хоть табличку такую делай и ставь к себе на стол.
Я бы, наверное, плюсанул, но всё же позиция немного эгоистична и в рамках проекта может быть вредна. Ситуации, когда возникает какой-то важный вопрос, который требует привлечения внимания разработчика и который гораздо важнее его «потоков», случаются. Факап, упавший сервер, критический баг… вариантов много и наверняка каждый сталкивался. И если в этот момент оказывается, что разработчик отъехал в магазин на пару часов и не известно, когда вернётся, то это плохо. Заводить на этот счёт баг в трекере, назначать совещание на завтра и сидеть на попе смирно — это верх бюрократии и неэффективности.
Нет, часы онлайн-присутствия и доступности должны быть обязательно оговорены. А о всяких «отъездах», «дневных снах», «купаниях в море тая» нужно предупреждать команду. Мир не сошёлся на программистах и в работу вовлечены многие люди. И работать так, чтобы не тормозить работу других — важный скилл.

Это решаемо, но в целом — да. Возможность хотя бы экстренно выйти на связь в случае ЧП — очень важна.


Либо же просто не работать в таких областях, где такое может произойти.

Однако в защиту товарища хотелось бы упомянуть, что обычно у нас капиталисты говорят о каких-то рисках и прочее, однако вот оборотной стороной (прибылью) никогда не делятся с работниками.
Не про безответственное отношение сотрудника, а про любителей каждую проблему выдавать за срочную и исключительно по вине сотрудника (неоплачиваемую).
Но опять же, лично мое мнение, что возможность вызвать сотрудника в случае ЧП в любое время — это реально важно. Факторы бывают разные. Невозможно все предусмотреть на всех уровнях.

Давайте начнём с того, что к серверам разработчик вообще никакого отношения не имеет. :) Это типично русские программисты — и швец, и жнец, и на серверах игрец (собственно, они потому и падают :))) ).
Есть продукт и период его разработки. Пока продукт не релизнут, его не существует и все проблемы решаются планомерно, вносясь в общий план работ. После релиза — ради бога, объявляется «неделя алерта» и все сидят и ждут грома с неба — я только «за»! Но в целом, «удалённая работа» должна иметь какой-то смысл для программиста! Фирма, не снимающая офис, не покупающая мне рабочее место, ПК, интернет, канцелярию, кулер и т.п. экономит сумашедшие бабки, при этом ни цента с этих бабок я не вижу. Но при этом они хотят, извините, «держать меня за яйца» весь рабочий день. Я вообще-то человек, у меня тоже есть куча проблем и если боссу достаточно развернуться задом и «поехать по делам», мне бы тоже хотелось иметь определённые рамки свобод.
Предупреждать — я могу, не проблема — просто тикнуть в мессенджере «busy». Но отпрашиваться по каждому чиху — точно не буду.

Хоть я и выступаю сейчас на стороне «любителя свобод», но я тоже не глупый — я понимаю, что есть разница между удалёнкой студента и зрелого разраба. Вот последнему я бы дал достаточную степень свобод, потому что «большие профессионалы» — редкость, им нужно создавать максимально удобные условия. А «контроль» таких вещей прост — результат.

И работать так, чтобы не тормозить работу других — важный скилл.

Важный скилл МЕНЕДЖЕРА ПРОЕКТА и «главного программиста». Чем лучше вы разделяете задачи, тем более независимы члены вашей команды.
Всё же программист большую часть времени тратит индивидуально, а совещания, хайпы и алерты — ну 1% времени!
Мир не сошёлся на программистах, но мы всё же «боги ПК» — это мы тратим чудовищные усилия, чтобы всё работало по нажатию одной конпки! Читаем тонны литературы, всякие мастер-классы, уроки, новости. Причём недостаточно прочесть и слыть профи до конца дней — мы каждый год окунаемся в какие-то новые вещи, технологии, подходы и постоянно учимся. А теперь вспомните свои студенческие годы — как, не поплохело? А у нас это «суровая реальность»! Мозг программиста насилуют каждый день :) и даже шахматы не идут ни в какое сравнение с продумыванием архитектуры какой-нть 1С! Собственно, за это мы и любим профессию — постоянный напряг мозга.
Я прекрасно понимаю роль разработчиков и сложности в их работе, поскольку я поработал и в этой роли, а также в роли менеджера, и в роли где-то между ними. И про поток, и про факапы, и про «вечнозанятых» бездельников, и про кошмарных недоменеджеров, и про планирование я тоже не по наслышке знаю.
Подход «вы же сэкономили на мне денег, но не поделились и продолжаете платить по рынку» не верен. Вам платят за ваши навыки исходя из стоимости, сформированной рынком. Если оплата вашего времени и навыков принимается за справедливую обеими сторонами, то уже никто никому ничего не должен. Всё остальное — плюшки. О каких бабках, которые вы не видели может идти речь? Может ещё все софтверные гиганты должны доплачивать каждому индусу на аутсорсе за то, что они на нём экономят? Тогда где экономия, простите?
Вы этим постом лишь подчёркиваете ту проблему, из-за которой многие компании не хотят работать с удалёнщиками. Даже если компания смогла осознать тот факт, что «8 часов + обед» не имеют никаких реальных оснований в IT, что большинство IT-специалистов способно работать откуда угодно лишь бы был интернет и ПК, что коммуникации возможно наладить на достаточном уровне и без личного присутствия (это пожалуй, второе по сложности), что людям можно доверять и оценивать по результатам (это первое по сложности), то вот проблему контролирования рисков вы
для них не решаете, а лишь ярко подчёркиваете. Они ваши слова увидят в виде «да, я могу пропасть среди дня, потому что я же дома работаю, а не в вашем офисе, значит у меня полная свобода, может я предупрежу, но не факт, тем более что у меня поток, так что могу и не ответить, даже если я тут». Удалённая работа это только работа «где хочу», а не «когда и как хочу».
Что до возвышения работы программиста над остальными в ИТ (и не только в ИТ), то нет, я и тут вас не поддержу. Да, это умственный труд, да, порой весьма напряженный. Но не надо думать, что мир сходится на программистах и они самые недооценённые и непонятые люди в сфере. И хороший менеджер, хороший дизайнер, хороший тестировщик, хороший девопс/админ, хороший аналитик тратят не меньше усилий, и точно так же учатся.
Что-то не понятно — о каком риске речь, и как он успешно контролируется с помощью офиса?
Вы узколобо смотрите на слово «деньги» — не про них же речь! Речь про то, что фирма имеет свой (немалый) профит, не снимая офиса и т.п. Я тоже хочу иметь свой профит в том, что могу сам выбирать рабочие часы, инструменты и т.п. Здесь нет никакого перетягивания одеяла, я (как человек) прошу элементарные удобства, которые никак не затрагивают работодателя.

Риски тут практически нулевые, потому что 1) вы перевираете мои слова — я указал, что МОГУ ставить статус отсутствия, вы же это вывернули в полную опциональность и неизвестность 2) Для удалёнщиков тоже есть «тестовый период» — если я вижу, что задача решается в адекватные сроки и человек отлично себя показал за 2 месяца, я со спокойной душой могу давать ему задачу и забывать на неделю 3) Риск есть даже у «планктона», ибо сотрудник просто не приходит на работу и процесс встаёт колом — очевидно, риск не больший, чем у удалёнщика с похмельем. :)

Я не хочу спорить со словами, которые вы сами придумали и сами отважно опровергаете. Я говорю, что программист — высокоинтеллектуальная работа и разумеется, я считаю программиста профессией высокого уровня — как разница между лудильщиком проводов и проектировщиком схем. Разумеется, люди интеллектуального труда ОБЯЗАНЫ обслуживаться по более лояльной категории, иметь какие-то привилегии и т.п. Лощёный менеджер-самоучка, размахивающий руками у доски, может быть заменён десятком других с ещё большей амплитудой рук. Разработчик заменяется как родной орган — только с кровью и мясом. Не будете бережно обходиться с ядром софтостроения, будете бесконечно сидеть в долгах и текучке, выжимая код с вечно недовольных рабов.
Хорошая аналогия — ресторан. Ты можешь сколько угодно раздувать щёки какой ты отличный менеджер, но все вы не стоите ничего, если у вас нет классного ПОВАРА. Так вот, повара — это мы, главные создатели продукта. Без программиста вся софтверная шарашка не стоит бумаги, из которой сделан ваш бэйджик.
Тут даже вопрос не про выставление статуса, а про адекватность и ответственность разработчика. Верно то, что адекватному и ответственному просто не нужен этот контроль от слова совсем — он только мешает, а вот неадекватного и безответственного человека — хоть законтролируйся — все равно в лучшем что-то ну очень посредственное получишь. В итоге вся идея контроля — не от большого ума и высокой компетенции менеджмента компании, сама цель непонятно — что хотят контролировать и чего добиться? Самоудовлетворения своей значимости (ай эм биг босс!) или поддерживать иллюзию контроля? В самом деле, вот просто житейски — какой из этого прок и кому?

И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Момент про «рабочие часы» прокомментирован выше.

Удаленная, как и очная работа бывает разной. В офисе вам могут предложить свободный график, а могут потребовать быть «от и до». Тут уж каждый сам решает, соглашаться ему на такие условия или нет.
Как и у других компаний на рынке, у нас есть некая отработанная схема, которую мы предлагаем кандидатам на вакансии. С удовольствием сотрудничаем с теми, кого она устраивает. Готовы к компромиссам в разумных пределах.

В статье описана некая общая схема командной работы. И команда здесь — ключевой момент. Членам этой команды для успешного достижения поставленных целей необходимо время от времени взаимодействовать между собой.
Описанная вами схема — с задачами на несколько дней или даже на неделю — у нас тоже может существовать для разработчиков в рамках отдельных проектов (при соблюдении определенных условий), либо для тестировщиков. К примеру, последние могут взять задачи на тестирование на неделю, самостоятельно с ними справиться в любое удобное время, а результаты занести в трекер.
Но мы делаем акцент именно на командной работе, поэтому и пишем о ней.
А на чем эти построения о «командной работе» основаны? Я, например, как человек приземленный, предпочитаю свои соображения соотносить с практикой. И мой опыт говорит, например, о том, что есть очень большие интервалы, когда никакой командной работы — не требуется, и даже сидя в офисе — ты сам в себе, в своей работе. Есть, разумеется, и напротив — интервалы, когда требуется командная работа — это особенно важно на этапе выработки концепции, на этапе тестирования большого блока, на этапе запуска и первых дней жизни проекта — тут разговора нет и никакому вменяемому разработчику не придет в голову уклоняться от этого. Но жесткая структура митапов — ежедневно, например, вне зависимости от контекста — это не более чем синдром контроля головного мозга, а не необходимость в виду реальных предпосылок. Это тот же микроменеджмент, задекорированный под благие намерения.

Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.

А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Спасибо за комментарий. Мы по-разному смотрим на вопрос командной работы.
Очень возможно — я не претендую на исчерпывающую полноту своего личного опыта, однако он имеет место быть, и, насколько мне известно — он у меня не уникален и довольно распространен. Соответственно здесь, в рамках обсуждения ваших методов контроля мы и делимся своими соображениями и опытом, что потенциально могло бы и вам пригодиться, если смотреть на излагаемое как на источник информации, а не попытку подорвать ваш авторитет или чего-то в этом роде.

Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
«Командная работа»? Вы что, американский футбольный тренер?? :))) Вы сами прекрасно знаете, что код пишется одним человеком. Им же (как правило) и сопровождается, ибо нет ничего хуже, чем лазить по чужим исподникам. Причём тут «команда»? Или вы под командой подразумеваете «мы наняли пучок студоты за одну зарплату, а ты, главный программист, должен беспрестанно работать для них справочником-учителем-цербером»? Ну, тогда в одном месте я видал такие «команды»!
Кратковременная помощь — это нормально и я это делаю. Опять же, никакой «команды» тут нет. И фиксы чужого кода я тоже не воспринимаю за какую-то «общность». Получается, что всё, что вы скрываете за словом «команда» — это держать удалёнщиков на непрерывном шухере «а вдруг КОМАНДА меня дёрнет по телефону?». Я правильно всё понял? :)
Нет, Вы не правильно поняли. Такой смысл мы не закладывали статью.
53 местоимения «мы» в тексте.
Вот читаешь, вроде всё хорошо, но ощущение «большого брата» не проходит.
К чему бы это?
Вот-вот :) «мягко стелят, да жёстко спать!». Ты вроде бы как и свободен, но только на длину цепи между тобой и ПК. :) Рабы выбирают себе цвет оков.
Sign up to leave a comment.