Комментарии 12
Окей, мы верим людям, а они насовывают нам глину и палки вместо красивых работающих систем. Как пофиксить? Единственный адекватный способ – кнут (зачеркнуто) чтобы людям было самим интересно и важно сделать круто.
Пример, как из ошибочных предпосылок сделать правильные выводы :-)
Палки и глина (в вашей терминологии) могут быть насованы и при наличии интереса у людей, например, в следствии их низкой технической квалификации или банальных ошибок.
Поэтому единственный правильный способ проверить работоспособность системы, это её тестирования. И доверие тут не причем.
Все равно есть вопрос -- делает ли человек максимум добросовестно (а уж что получилось -- второй вопрос). Или человек делает минимум, абы прошло формальные проверки (и если что не так -- с него взятки гладки).
Все равно есть вопрос -- делает ли человек максимум добросовестно (а уж что получилось -- второй вопрос). Или человек делает минимум, абы прошло формальные проверки ....
А это никого не должно волновать. Сотруднику платят за результат, а не за его душевный комфорт, даже не смотря на то, что связь между этими понятиями реально присутствует.
Это волнует с точки зрения планирования и средней скорости продвижения. Душевный комфорт как таковой не волнует зачастую никого, даже самого сотрудника. Но все хотят чтоб дела делались.
Сегодня тебе кажется что это хороший подход, через год ты смотришь на свой же код со словами "как я это вообще написал?"
Поэтому я склонен согласиться с datacompboy. Шанс того что человек подумает о рефакторинге гораздо больше когда он заинтересован.
Вопрос №1: как мы убедимся, что работа реально делается?
В интеллектуальной деятельности не работает учет рабочего времени. Если разработчик мылся в душе, а ему пришло в голову решение по оптимизации работы микросервисов, это заносить в тайм-шит?
Получается, оценивать работу можно только по результатам. Как убедиться, что результат работы реально ок норм, а не просто рандомный кусок из глины и палок? А никак, кроме как поверить человеку, что он добросовестно делает свою работу.
Огонь 🔥 Неужели существуют менеджеры которые считают работу не по часам и строчкам коммитов.
менеджеры которые считают работу не по часам и строчкам коммитов.
Я не в коем случае не отстаиваю необходимость палочного режима с учетом часов, строчек и вот этого всего, однако общаясь с некоторыми разработчиками в голову невольно лезут нетленные строки
Здесь женщины ищут Но находят лишь старость
Здесь мерилом работы Считают усталость
Палки и глина
Везет вам, у вас глина...
Пример, как из ошибочных предпосылок сделать правильные выводы :-)
Палки и глина (в вашей терминологии) могут быть насованы и при наличии интереса у людей, например, в следствии их низкой технической квалификации или банальных ошибок.
Поэтому единственный правильный способ проверить работоспособность системы, это её тестирования. И доверие тут не причем.
В уравнении эффективности работы есть много вводных: компетенции, координация, коммуникация, лидерство, среда, нормы продуктивности. При прочих равных, если вы возьмете людей с одинаковой технической квалификацией и внимательностью, сотрудники с высокой внутренней мотивацией и интернализированными стандартами качества работы покажут лучшие результаты, чем другие. Тестирование — это инструмент проверки результатов работы, а не управления качеством личной вовлеченности в задачу.
Доверие же здесь и правда не при чем, так как оно упомянуто в этом абзаце исключительно для перехода от одной мысли к другой: от базовой ценности "доверие" к базовой ценности "внутренняя мотивация".
Создаем архитектуру репозиториев с доступом по командам (привет, RBAC).
По командам, если команды в приоритете, а по роли, то вторичнее, то ABAC
Хорошо задокументированная организационная культура в кнутах и пряниках не нуждается 🙂
Вот я если честно не очень понимаю почему асинхронная коммуникация является бескомпромиссной целью. Начнем с того что не все одинаково понятно могут описать тикет, проблему итп. Перейдем к тому что постоянно нужно перечитывать тонны логов в git, jira итп. И наконец к мотивационной части, описывать то что ты делаешь, комментировать и выискивать всю инфу это рутинная скучная часть работы, высасывющая мою мотивацию. Но главное это то что при асинхронном подходе уходит чуствто завершенности: не хватает инфы, кода, бэка, знаний? Комментируй и жди ответа. А что делать пока ждёшь, возьми другую таску с полки. И вот ты сидишь весь такой асинхронный с пятью тасками, переключаясь между бранчами при поступлении новой инфы, потому что приоритеты у них разные и не закончив не одну из них, заканчиваешь свой рабочий ден / неделю. Для меня в этом мало мотивации, конечно все от типа человека и его предпочтений зависит, но любым решением "для всех" мы делаем чью-то жизнь легче а чью-то сложнее.
Управление распределенной командой на GitHub – а что, так можно было?