Drive your career as React Developer with Symphony Solutions!
×Закрыть

Карантин: Как эффективно управлять удаленной командой

Некоторые владельцы бизнеса не верят в идею эффективной удаленной работы. Кто будет контролировать разработчиков? Как им доверять? Как установить с ними четкую связь, если они на 100% находятся удаленно?

Как владелец компании, начинавший 5 лет назад полностью удаленно, мне есть чем поделиться. В этом материале я постараюсь рассказать о некоторых практиках удаленного управления командой которые считаю наиболее эффективными (по крайней мере, они до сих пор успешно работают для UppLabs). Карантин коснулся всех. И независимо от вашего типа бизнеса, если вы вынуждены работать из дому, попробуйте применить мой подход. Главное — не сдаваться и помнить, что когда-то это все закончится, и бизнес нужно будет поднимать заново. Так что лучше вообще не останавливаться. У вас все получится!

Лучшие практики по удаленному управлению командой

Методы управлением проектами могут дать много пользы! Выберите или постройте наиболее подходящий для вашей команды и проекта и следуйте ему!

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

Есть несколько методов управления проектами, которые пригодятся вам в работе:

Agile — сотрудничество для итеративного выполнения любых работ.

Agile представляет собой набор руководств, изложенных в манифесте Agile, состоящего из четырех принципов:
Люди и взаимодействие важнее процессов и инструментов;
Работающий продукт важнее исчерпывающей документации;
Сотрудничество с заказчиком важнее согласования условий контракта;
Готовность к изменениям важнее следования первоначальному плану.
Таким образом Agile — это скорее философия и набор ценностей, а не процесс, который вы можете напрямую применить к проекту. И с этой философией не поспоришь. К семейству Agile методологий управления проектов относятся Scrum, Kanban, XP.

Scrum — метод, позволяющий небольшой, многофункциональной, самостоятельной команде быстро достигать результата.
Scrum состоит из следующих артефактов: итерация (Sprint), список задач (Product Backlog), список задач отобранных в текущую итерацию (Sprint Backlog), диаграмма сгорания задач (Burn-Down Chart), ежедневное совещание с командой (Daily (Standup) Meeting), планирование итерации, демонстрация результата итерации, ретроспектива итерации, канбан доска (Kanban-board) и некоторых других. Цель Scrum — улучшить общение, командную работу и скорость разработки проекта и добавить возможности некоторого планирования с помощью оценок сложности задач (Story Points). Scrum наиболее подходит для разработки продуктов, где достаточно большой и приоритезированный список задач (Product Backlog), а также клиент готов ждать окончания итерации (в среднем 2 недели), чтобы получить результат работы. Также Scrum позволяет контролировать эффективность команды (Velocity).

Kanban — используют для повышения скорости и качества результата проекта за счет повышения наглядности выполняемой работы и ограничения многозадачности. Во многом он похож на Scrum — речь идет выше, но в нем нет итераций и всего что с ними связано: диаграмма сгорания задач (Burn-Down Chart, планирование итерации, демонстрация результата итерации и т.д. Основными методами являются визуализация рабочего процесса с помощью канбан доски (Kanban-board), ограничение выполняемой работы. Эта методология подходит для более динамичных проектов, где задачи и/или их приоритеты могут меняться в любое время.

Метод Xtreme Programming (XP) — надежное выполнение разработки для обеспечения качества.
eXtreme Programming (XP) определяет ценности и процессы для улучшения качества программного обеспечения и влияет на процесс реагирования в связи с меняющимися требованиями клиентов. Ценности или принципы очень похожи на Scrum в отношении простоты, общения, обратной связи, уважения и смелости. Что действительно отличает этот метод от Scrum, так это определение правил или предписывающих процессов. Некоторые из них похожи на Scrum, но существуют правила, касающиеся технических приемов разработки кода и тестирования, которые делают его специфичным для проектов разработки. Эти правила изучение поведения пользователей, TDD (test-driven-development), парное программирование и непрерывную интеграцию между участниками.

Lean — оптимизация и устранение лишнего, чтобы достигнуть «большего результата с меньшими затратами».
Метод Lean — это метод управления проектами, с фокусом на теме эффективности. Предполагают, что главная идея Lean — делать больше с меньшими затратами. Он начинается с определения ценности, а затем максимизирует ее за счет постоянного улучшения путем оптимизации ценности и устранения лишнего. Он предполагает, что вы можете делать больше с меньшими затратами, устраняя три дисфункции, которые создают лишнее (3 M):
1. Mуда (об искоренении лишнего — деятельность, которая направлена на удаление процесса или чего-либо, что в конечном итоге не увеличивает ценность для клиента).
2. Mура (об устранении отклонений — устранение издержек, которые создаются посредством отклонений от стандартного процесса).
3. Мури (об устранении перегрузки — оптимальная мощность работает на 60-70%).

Waterfall — планирование проектов целиком, затем выполнение по этапам.
Метод Waterfall имеет очень простой подход, основанный на детальном планировании, которое совершается только раз, в отличие от поэтапного и итеративного метода Agile. Принцип методологии легко понять, потому что он состоит в том, что вы просто составляете хороший план и выполняете его. Конечно же, в действительности все отнюдь не «просто». Менеджер проекта, как правило, несет полную ответственность за проект. Работы планируются заранее, а затем выполняются в строгой последовательности в соответствии с требованиями, для того чтобы обеспечить выполнение проекта за один очень долгий цикл. У клиента уже нет никакой гибкости изменить план работы, до его завершения. Так что в чистом виде этот подход уже не очень актуальный, хотя некоторые его артефакты используют и сейчас, например: очень часто от клиентов можно услышать запрос на точную оценку проекта.

Зачем столько методов? Потому что каждый проект и каждая команда имеют свои особенности. Но если проанализировать подход, удобство, или взять артефакты из какой-то методологии и работать по оговоренном вашей командой подходе в итоге окажется намного проще. Определенный процесс принимается для всех, и все по нему работают.

● Автоматизируйте ваши настройки, там где это возможно
Для каждого вида деятельности или задачи создайте простое руководство к тому, как начать работу. Поначалу это может быть сложно, но когда все будет готово, это существенно упростит и ускорит множество процессов.

● Всегда устанавливайте четкое определение выполненной задачи
Объясните, что вы имеете в виду под определением «выполненная задача», чтобы впоследствии не возникало вопросов и недоразумений. Кроме того, необходимо описать параметры такой выполненной задачи в документе, к которому каждая удаленная команда имела бы доступ.

● Всегда устанавливайте дедлайны
Если у вашего сотрудника нет строгих сроков выполнения задачи, работа может длиться бесконечно, потому что некоторые задачи могут оцениваться как задачи с более высокими приоритетами. И каждый раз он будет отвлекаться на что-то «более важное», не завершив начатое ранее. Таким образом, финишная черта таких задач может быть сдвинута на неизвестное время.

● Установите каналы связи
Не стоит недооценивать разницу часовых поясов. Необходимо установить время, которое лучше всего подойдет для ежедневных звонков со всей вашей командой. Воспользуйтесь лучшими каналами управления бизнесом и коммуникациями в 2020 году:

Коммуникация:
— Slack
— Google Hangouts
— Skype
— Zoom
— RingCentral

Задачи управления проектами:
— Jira
— Trello
— GitLab
— Asana
— Zapier (для интеграции)
— Redmine

Обслуживание клиентов:
— Zendesk
— Hubspot
— Hootsuite
— MailChimp
— Zoho
— Calendly
— Basecamp

Управление файлами:
— Dropbox
— Google Docs и другое... Не пренебрегайте электронной почтой для важных соглашений и переговоров с вашими клиентами.

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

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

● Автоматизируйте все, что можете
Автоматизация процессов позволяет членам команды тратить свое время и усилия на эффективную работу, вместо того чтобы пытаться выяснить обыденные рутинные процессы.

Буду откровенен, что каждый проект несет какие-то сложности и организовать идеально процесс не так просто! Но я надеюсь, что эта статья будет хоть немного полезна вам. Я готов ответить на вопросы и помочь вам с советом в будущем, если будет такая необходимость!

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Потому что все это лишь в сказке просто. На все надо много усилий.

А почему не доверяют сотрудникам на удаленке? Потому что не знают как их контролировать.
Просто попросту не знают, хотя все можно сделать. Вот приведу для примера один и самый простой способ. Для этого нужна четкая система, чтобы все лежало по полочкам. Один из самых приятных и удобных сервисов для этого — Trello. В его основе лежит канбан-доска, на которой можно создавать карточки с задачами и передвигать их по этапам: нужно сделать, в процессе и готово. Также там можно ставить ответственного за задачу и сроки, к которым нужно ее завершить. Конечно, функционал на этом не заканчивается, но здесь мы рассматриваем основное:) Больше можно узнать здесь, организовывала процесс удаленки именно с помощью этой статьи, довольна работой на 95%, Но понятно, что основное место должна занимать коммуникация в реальном времени.

Просто попросту не знают, хотя все можно сделать.

Более того и не хотят. Это надо что-то делать для оного, а лень.
Ну еще многие получают удовольствие от созерцания своего стада в опенспейсе.

Шёл 22-й день карантина. Статьи про удалённую работу, так и не утихали.

Можна просто не заважати працювати своїми ефективноменеджерськими свистопердульками і оперативно викидати на мороз філонщиків

Теоретично можна все, навіть флюгегехаймен для них в офісі мати. Але ж не склалося...

Используйте видео чаты, чтобы сохранить «человеческое лицо» при общении со своими сотрудниками и клиентами

Ненавижу видеочаты. И вообще, все эти звонки нужны только менеджерам. Для программиста это пустая трата времени.

да, технические вопросі в большинстве не порешаешь на таком митинге.
А время потратишь

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

А вы видели успешные проекты, где нет менеджеров, а есть только программисты?

Программисты, один из программистов, взявший на себя роль лида (неформально и вообще так вышло), и заказчики? В таком виде видел легион успешных проектов.

Я спросил не про проекты, сделанные на коленке в гараже, а проекты с годовым оборотом десятков миллионов долларов

Почему тогда, имея такой ответ, огромное количество компаний сейчас не может нормально перевести свой штат на «удаленку»?
Почему не могут организовать процесс работы?

Названия компаний в студию ! Иначе это абсолютно голословное заявление

мониторить работу сотрудников, проходя у них за спиной, намного проще

Это 5 :)

мониторить работу сотрудников, проходя у них за спиной, намного проще

А интересно как? не сидит в порнхабе — уже плюс в карму ? :8))

не сидит в порнхабе — уже плюс в карму ? :8))

а если сидит и совпадает по предпочтениям то может быть и 100500 плюсов в карму )))

Некоторые владельцы бизнеса не верят в идею эффективной удаленной работы. Кто будет контролировать разработчиков? Как им доверять??

На это давно есть ответ, причём он один и тот же для удаленщиков и офисных сотрудников, а ты вообще тупо привёл список популярных базвордов ПМов в ИТ

Чувак при чем тут удаленка вообще?

Чувак не управленец, чувак писатель. Жрец ctrl-c и гуру ctrl-v

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

чувак, никакой скрам/лин не решает это проблему. это проблема только в том, что в Украине большинство менеджеров долбоебы которые попали на свои должности случайным образом.

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

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

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

Считается, что человек должен учиться сам, на ошибках.
И тут проблема как у врачей, примерно. Те прячут свои ошибки на кладбище, а ПМы в бюджетах и овертаймах.

Почему не могут организовать процесс работы?

Потому что впервые в истории IT на удаленке находится от 90 до 100% персонала контор. Соответственно проблемы, которые вылазят — также во многих случаях вылазят впервые.

Такое происходит потому что никто не заморачивается над построением организации, систем контроля и отчетности

Не заморачивался — так точнее. И не надо про всех :)

многие сотрудники работающие из дому (и сейчас многие из них) попросту халатно относились к своим обязанностям

Т.е. менеджеры никогда не слышали ни о перформанс, ни о компетенси менеджменте? Тогда не тех увольнять надо :)

представьте себе процесс найма нового сотрудника в условиях карантина

Мне представлять не надо — я этим сейчас ежедневно занимаюсь. Чем Вы хотели меня напугать :) ?

Неужели это легче чем попробовать построить систему контроля и мониторинга для всей команды

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

Какой такой «ответ» вы имеете в виду?

Мотивация

Сотрудник, которого тошнит от компании, проекта, низкой зарплаты, менеджмента или коллег, будет работать из рук вон плохо и в офисе, и с надсмотрщиком за спиной. Сотрудник, которого устраивает все перечисленное, будет работать нормально и дома. Сотрудник, которого большинство из перечисленного устраивает + что-то вдохновляет, будет работать отлично.

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

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

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

Не доверяют, потому что (внезапно) в офисе ни у кого нет нормальных процессов. Процессы — это система, да. Но в первую очередь не система контроля (на удалёнке доступ к JIRA не дают, что ли?), а система управления, которой должны следовать именно менеджеры в первую очередь, и подавать пример. Чтобы бэклог был в порядке, без отсортированных по релизам/спринтам/приоритетам тасок с acceptance критериями и чётким ТЗ не начиналась работа... чтобы дизайн предварительно проработал архитект или техлид или кто там за это в ответе. И далее мы приходим к тому, что контакт с девами-то и не нужен особо, а нужен там, где «сделай что-нибудь, как-нибудь, вот тебе доки 2 тыс. лет до нашей эры, ну всё, давай эстимейт». Ну камон, сколько Вы знаете проектов, которые не взлетели из-за плохого контроля? И сколько Вы знаете проектов, которые не взлетели по другим причинам, которые к контролю не имеют отношения?) Потому что BA-часть и дизайн пролюбили, или не захотели заказчику признаваться, что не взлетит так, как он хочет, или всех похоронит техдолг — главное ж деньги освоить, а там уже можно за спинами ходить и эстимейты требовать...

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

Чтобы бэклог был в порядке
без отсортированных по релизам/спринтам/приоритетам тасок с acceptance критериями и чётким ТЗ не начиналась работа...
чтобы дизайн предварительно проработал архитект или техлид или кто там за это в ответе

You are not enough agile Ⓒ

IT индустрия — это бизнес. И как и любой другой бизнес он должен приносить деньги.
Пока Вы пишите требования и гоняете задачи по беклогу — другие продукты выходят в масс маркет и начинают приносить прибыль. ( про " да я 20 лет в NASA на одном проекте" мы давайте сейчас разговаривать не будем :) )

IT индустрия — это бизнес. И как и любой другой бизнес он должен приносить деньги.

Шось мені підказує шо найбільший прибуток в айті приносять порнхаби. Поправте мене якшо я не вгадав.

Ну, тогда давайте называть вещи своими именами для подобного контекста).
1. Большая часть рассказов про процессы в компаниях — корпоративный буллшит, т.к. процессов просто нет, и строить их никто не будет.
2. Менеджеры выполняют функцию прокладки, а весь «менеджмент» состоит в тушении пожаров и раздаче пинков.
3. Многие работали, работают и будут работать через ж, потому что вынуждает специфика, поэтому см. п. 1. Таким образом:
3.1. У разработчиков всегда есть железобетонные аргументы на «что-нибудь как-нибудь» выкатить эстимейт «когда-нибудь» и снять с себя любую ответственность за результат.
3.2. Любой проект — это рулетка от начала до конца, и попытки что-то там исправить не имеют смысла.

...что там было про контроль девелоперов на удалёнке for the win, я забыл?)

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

Лол, а вы думаете эти другие проекты не гоняют задачки по бэклогу? У них наверное экстрасенсы в команде, для которых jira не нужна совсем.

командный дух

такий прям дух шо й через скайп штинить.

огромное количество компаний сейчас не может нормально перевести свой штат на «удаленку»? Почему не могут организовать процесс работы?

цитата
8 шишек, которые я набил, управляя удаленной командой
1. Не все слышат / читают то, что я пишу. Многие слышат / читают то, что хотят прочитать

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

2. Мало кто способен к самоорганизации

Все думают: «Да я точно смогу! Это же просто: включил компьютер и работаешь». Но на деле способны самоорганизовать себя единицы. Дома слишком много соблазнов: лечь на диван и уснуть, пойти помогать родителям, выгулять собаку, отправиться в гости, посмотреть интересный фильм. В офисе гораздо проще сосредоточиться именно на рабочих вопросах, проверено! В итоге руководителю надо обучать сотрудников как организовать себя, а ведь далеко не все готовы пускать чужие правила в свою личную жизнь.

3. Сорок джуниоров не то же самое, что сорок миддлов

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

Кирилл Брагин
www.e-xecutive.ru/career/hr-management/1987824-8-shishek-kotorye-ya-nabil-upravlyaya-udalennoi-komandoi
(конец цитаты)

я на удаленке уже года 4

подтверждаю — большинство коллег не дотягивают до требуемого уровня по пп 1-3
они привыкли что с ними нянчатся в офисе, разжуют ТЗ, утрут слезки что что-то не получается, уболтают работать, а не тупить, заметят прокрастинацию или неэффективную работу и подойдут помогать, и т.п.

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

у меня есть подозрение что джунов независимо от «опыта» возраста и лычек всегда большинство по крайней мере я постоянно сталкиваюсь с командами в которых кого-то надо «учить и доделывать и уделять массу времени» и тут интересно видимо как набирали бывает больше половины а бывает меньше ))

подтверждаю — большинство коллег не дотягивают до требуемого уровня по пп 1-3
они привыкли что с ними нянчатся в офисе, разжуют ТЗ, утрут слезки что что-то не получается, уболтают работать, а не тупить

просто поболтают с ними ни об чём ну а что? ))

и подойдут помогать, и т.п.

это вообще страннейшая вещь уже неоднократно встречал «встречный вопрос» «ну ты сделаешь?» йопта человек простите это же ж твоя задача! ))

сирёзно многие привыкли к «помощи» когда кто-то сделает за него например погуглит решение но стоп чувак у тебя такой же ж гугл такой же ж интернет такой же ж комп те же ж условия задачи какие ты отдал «на помочь» мне почему я нагуглил а ты нет? ))

сирёзно многие привыкли к «помощи» когда кто-то сделает за него например погуглит решение

Бывает вообще всё в документации к библиотеке есть, надо только почитать. Но инструкции для слабаков, лучше дернуть кого-то, собрать митинг или спросить на SO

Вот смотри, ты 5 км по Киеву на такси, машине, общественном транспорте поедешь или пешком пойдешь? А если повезут бесплатно?
Так и тут сильно легче спросить у кого-то, чем самому в доках ковыряться.

«Дай человеку рыбу, и он будет сыт один день. Дай человеку удочку и научи ловить рыбу — и он будет сыт весь год»

Нафига ее ловить, если можно выпросить?

Нафига ее ловить, если можно выпросить?

100%

Бывает вообще всё в документации к библиотеке есть, надо только почитать.

да, и настолько часто, что я так и говорю:
«Большинство разработчиков не читают ни документации, ни спек, ни даже кода на который собираются завязать собственный код»

и может кому и нравится быть ходячей спецификацией, когда к тебе крестный ход,
но меня раздражает ею быть.
поэтому — пишу.
но все равно — «не читают» а спрашивают.
и все равно итог:
Не все слышат / читают то, что я пишу. Многие слышат / читают то, что хотят прочитать

собрать митинг или спросить на SO

и когда смотришь MR, ё... целых 3 митинга было об этом, и все равно, как и не было их...

вобщем кто чем удручен о состоянии дел у нас в разработке
кто победой Electron’ов и пластмассового мира
а я — тотально жутко низким уровнем способностей к самостоятельной работе

а я — тотально жутко низким уровнем способностей к самостоятельной работе

Избыток информации и требования к скорости выдачи какого-то результата ограничивают человека в возможностях ее осмысливать и анализировать (мозг ограничен размерами черепа, отводом тепла, продуктов жизнедеятельности и подводом продуктов питания ему).

Вот тебе пример. В 80-90-х я какую статью мог внимательно разбирать, анализировать, обдумывать пол года. Сейчас максимальное время на заюзание ее результатов 1-2 недели.
Итог, уже толком не разбираясь, просто прилепливаешь и веришь, что будет работать так, как предполагается.
В программинге все еще хуже.

это все понятно, и в целом согласен.

но насчет мозга — в том то и дело что он практически у всех одинаков.
а вот способы обработки информации, набор персональных методик quick & dirty analyse, эвристик — у людей разный.

в этом и есть главная разница между «мозгами».

но насчет мозга — в том то и дело что он практически у всех одинаков.

Только, когда вынут из трупа он по форме похож.
А так он сильно не одинаков. Но ограничения у всех близкие для него.

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

Вот тебе пример мой вчерашний. Я питон знаю плохо. Вчера на matplotlib слепил отображение 4 изображений с прямоугольниками и двумя графиками. Работает жутко медленно — отображение около 0.5 fps. Сколько времени мне нужно, чтобы сделать отображение на 30 fps этого же?
В результате я буду искать что-то готовое, что сделано кем-то уже и как-то присобачу, времени и интереса, чтобы разбираться в нюансах matplotlib у меня нет.
У меня есть более важная задача на дальше — избавиться от Detectron2 (скорее всего переделать их нейросетку под другой движок, что С++ умеет) или подождать немного, когда кто-то другой это сделает, а я тупо заюзаю, не разбираясь в деталях. По сути наговнокожу.
В итоге, в части отображения у меня будет некий говнокод и не более.

Итак, мы имеем говнокод в квадрате с

тотально жутко низким уровнем способностей к самостоятельной работе
мы имеем говнокод в квадрате с

речь не о говнокоде. у него много причин.
например ограничение по времени.
или нехватка специальных знаний

речь о том что когда и дашь время, объяснишь — все равно часто будет именно он.

и это давно так, различие между «мозгами»
цитата:

Предположим, что вы хотите убедиться в том, хорошим ли умственным аппетитом обладает некое человеческое существо. Дайте ему в руки краткий, хорошо написанный, но отнюдь не увлекательный трактат на какую-нибудь популярную тему, т. е. своего рода булочку для ума. Если трактат прочитан с неподдельным интересом и сосредоточенным вниманием, а читатель по прочтении может ответить на любой вопрос, относящийся к содержанию книги, то его ум работает превосходно. Если же ваш подопечный через несколько минут вежливо отложит предложенную его вниманию книгу в сторону или немного погодя заметит: «Я не могу читать такие глупые книги! Нет ли у вас второго тома „Загадочного убийства“?», то вы с полным основанием можете считать, что с умственным пищеварением у данного читателя не все обстоит благополучно.

Пища для ума. Льюис Кэрролл

доку, спеки, а тем более код читать скучно.
веселее — писать!
с ударением на И....

в итоге — и не вырабатывается навык.

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

забавное что встречал
рассписал псевдокодом, разложил по классам интерфейсам паттернам
ок. делай
присылает MR — ничего общего :)
так сказать — сдал экзамен, теперь можешь забыть :)

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

речь не о говнокоде. у него много причин.

Это итоговый результат. Мне часто лень всю логическую цепочку выписывать.

например ограничение по времени.
или нехватка специальных знаний

И это приводит к тому, о чем ты выше написал.

А кто будет использовать данные методологии, кто их на самом деле знает и самое главное умеет применять на практике + еще и обосновать использования её. За всё время я единицы таких встречал. Все слышали и читали про Agile и конечно (model or framework) Scrum со своими спринтами, бэклогами, эпиками а на деле осознано применяют единицы, остальные просто щеки надувают.
Кроме этого на Scrum «свет клином не сошёлся» мы можем выбрать модель управление проектом RAD, FDD или DSDM. И в разных ситуациях (проектах) каждая из них идеально подходит + нужно еще донести их до команды.
Я к тому, что большая половина их не использует должным образом, а вторая не до конца понимает зачем и почему .

маленькая помарка в аббревиатуре

DSDM

BDSM. да. наверное это самая популярная модель управления :)

Потому что все это лишь в сказке просто. На все надо много усилий.

А почему не доверяют сотрудникам на удаленке? Потому что не знают как их контролировать.

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

Столько бла-бла-бла уровня автогенератора текста. Скажи ещё «дякую» и «остаточнэ прощавай»

Поскольку вы уже потратили столько своего времени на целых два комментария без конструктива, скорее всего, вы просто-напросто гуру троллинга :).

DOU уже однажды вакцинирован Паламарчуком. Ты точно не Паламарчук?

Ваша удаленная команда должна постоянно коммуницировать между собой, но при этом не впадать в крайности.

Мне раз в неделю в чатике пару предложений написать вполне норм

Дай угадаю, первое предложение — тікай з городу

А как у вас по загрузке работой?

Лучшие практики по удаленному управлению командой
Agile
Scrum
Kanban
Метод Xtreme Programming (XP)
Lean
Waterfall

Не угадал. два :)

Спасибо, за обратную связь. Буду благодарен, если поделитесь вашимы мыслями по данной теме.

Я знаю тхэквондо, каратэ, джиуджитсу и много других страшных слов

Подписаться на комментарии