К сожалению статья выглядит неправдоподобной. По пунктам: 1. "Мы сжигаем деньги инвесторов" - внезапно оказалось? А до этого не сжигали? Вообще это модель работы стартапов, а у компании судя по описанию уже есть работающий продукт, раз даже платежный модуль для него сделали, и вообще компания давно работает. 2. "Компания серьезно меняла свою бизнес-модель, и скорость вывода продуктов на рынок стала жизненно важной" - и ни слова об этой бизнес-модели и причинах ее изменения. Вот так жила-была компания, зарабатывала деньги и внезапно решила поменять бизнес-модель. Причем на такую, при которой даже платежные модули не нужно тестировать. 3. Несколько раз упоминалось о том, что фиксы и рефакторинг будет потом. Что мешало сразу спросить: "Когда потом?" и написать тут свои выводы? Потому что одно дело если у СТО (который вообще-то технический директор, и должен понимать что полгода-год такого кодинга и дальше никаких "быстро в продакшен" не будет, потому что 9 женщин не родят ребенка за месяц) есть конкретные сроки и план, например: "Нам нужно в течение полугода вывести продукт на рынок и показать рост, после чего мы переходим в спокойный режим и выделяем одну неделю в месяц на рефакторинг и лучшую архитектуру". А если же он просто говорит "потом-потом", то очевидно что никакого плана у него нет, и нужно честно это признать. 4. Автор принимает за аксиому что "бизнесу нужно быстрее", даже не анализируя - действительно это нужно или кто-то решил себе бонусов заработать. Понятно что это не его работа, но это позволит ответить на вопрос "С кем я работаю", ведь это важно программисту.
А эти "лучшие умы" точно с нами в одной комнате? Потому что есть подозрение что ее запускали так же, как и Stadia - не проанализировали предыдущие проекты, не улучшили в них ничего и тупо сделали плюс-минус тоже, наступив на те же грабли. В итоге Google+ загнулся, потому что пользователи не смогли ответить на вопрос: "А зачем мне еще одна такая же социальная сеть?".
Статья понравилась. К сожалению ей не хватает конкретных примеров правильной и неправильной интерпретации основных принципов Agile, в формате "Этот принцип поняли неправильно, сделали так, это привело к такому провалу - а вот здесь поняли правильно, сделали так - и это привело к такому результату". Например: в одном стартапе не стали делать документацию, и в итоге, когда они начали расширятся после успеха MVP, из-за того, что новые сотрудники не могли быстро вникнуть в проект, второй этап длился в 2 раза дольше запланированного. А в другом стартапе ввели правило - после передачи задачи в тестирование разработчик не переключается на другую, а садиться и пишет по ней документацию, начиная с самых важных и критических частей. И это даже почти не сдвинуло сроки выхода MVP, потому что когда задача возвращалась из тестирования, разработчик был в контексте и быстро правил баги. А вот второй этап разработки после релиза они сделали почти вовремя, потому что новые разработчики смогли быстро влиться в проект благодаря документации. На мой взгляд отсутствие таких примеров как раз одна из причин, почему Agile выродился до ритуалов - Agile Manifesto - это лозунги, а персоналу нужны подробные инструкции что и как делать, иначе им банально не на что опереться, интуитивно они не понимают что за лозунгами стоит. А раз подробных инструкций нет, они начинают фокусироваться на то, что есть, на том, что они могут сделать - то есть на ритуалах.
Германия предлагает беженцам оплату квартиры, медицинской страховки и 550 евро в месяц на жизнь, которых хватает не только на еду, но и на одежду и т.д. Не говоря уже о перспективах для тех, кто выучит язык.
А потом сотрудники уходят в курьеры, таксисты и контрактники, и внезапно демотивация начинает играть роль. А если ломается в условиях санкций дорогой станок, который уже не могут отремонтировать специалисты из-за рубежа, то остается один вариант - мужик, который работал с ним последние 10 лет. Но тут внезапно он уходит на 150к, потому что руководство "не может ему повысить зарплату со 100к до 120к, бюджета нет". И миллионы убытков. В мирное время их бы никто не заметил, а сейчас, когда они множатся - упс.
Большое количество людей не продумывают свою жизнь. Я в свое время очень удивился, когда понял, сколько людей хотят после школы просто найти работу и жить в свое удовольствие в свободное время, и не задаются вопросами: "От какой работы я буду получать удовольствие?", "Что конкретно я хочу делать?", "Как мне в этом заработать?". Поэтому часто продавцы и т.д. не отчаявшиеся, а скорее зазомбированные. Пример с курьерами, таксистами, сейчас добавились сотрудники пунктов выдачи очень показателен - ведь зарплату им платят агрегаторы, которые просчитав экономическую модель поняли, что чем больше людей - тем больше денег.
Проблема в неудачном термине. Вы же сами описали, что на самом деле это значит: "Оцени объективно что у тебя есть сейчас, какие у тебя есть ресурсы для достижения цели и уже отталкиваясь от этого строй план достижения цели - в том числе план как получить тех ресурсы, которых у тебя не хватает". Или так важно найти одно слово, которым можно выразить это предложение?
Дело в том, что этот совет бесполезен без второй части - "не пытайся быть другим". То есть человеку говорят "будь самим собой" когда он неудачно пытается строить из себя другого, например - много и громко шутить в компании, воображая себя успешным стендапером, когда большинство его шуток вызывают испанский стыд.
Редколлегия не должна ничего перепечатывать, написано же - их задача проверить статью, чтобы не допустить публикации неправды. Из-за тщательности проверки у журнала такой высокий рейтинг, и по сути за это и платят люди, которые хотят статью опубликовать, 4к - за проверку. Эффективные же менеджеры решили что "пусть лохи платят 4к за то, а мы будем быстренько статьи проверять частично с помощью ИИ, и заработаем тонну бабла".
Если кому-то из ваших сотрудников нужен коллективный контроль, то перестаньте нанимать людей из школы, берите уже взрослых. Проверка эмоционального состояния ненависти к дебильным созвонам. Замерил - чем меньше созвонов - тем больше производительность.
Даже пароль вспомнил, чтобы прокоментировать. По порядку: 1. "можно поставить цель: «Увеличить количество заполненных анкет на сайте в два раза» " - вроде очевидно, что ставить ее нужно не команде разработчиков, а как минимум Product Owner'у? Или вы из тех, кто нанимает бригаду строителей и говорит "постройте мне классное офисное здание, чтобы хотелось арендовать в нем офис. И сами придумайте план и т.д., в общем сделайте всю работу архитектора и маркетологов". Причем таких команд разработчиков - единицы, и стоят они столько, что вам точно не хватит денег. 2. "Если нет целей" - а зачем вы вообще начинаете проект без целей? 3. " Ответственность за успех разделяется" - как конкретно она разделяется? Разработчики получат долю прибыли? Премии? Или вы из тех, кто думает, что "программировать - это легко, и они не должны за это получать такие бабки, поэтому нагрузим их еще остальным"? 4. "Клиент, ожидая помощи от команды, не сформулировал цели" - если клиент настолько беспомощный, что не в состоянии В СВОЕМ ПРОЕКТЕ, который он по определению должен понимать лучше всех, определить очевидные приоритеты, то нехер на команду разработки перекладывать ответственность. 5. "Правильная цель должна быть конкретна, измерима, достижима, релевантна и привязана ко времени " - а еще остался бизнес, который не способен, пусть и с подсказками ПМа, это сформулировать? Резюме: статья выглядит как очередная попытка не умеющего в управление переложить свою работу на исполнителей без дополнительной оплаты. И каждый раз эта идея терпит крах, потому что люди в разработку идут не для того, чтобы заниматься задачами управления и маркетинга, а потому что им нравится программировать/тестировать/дизайнить согласно поставленным задачам за нормальные деньги. А клиенту, если он не может сам разобраться со своими целями и т.д., нужно нанять Product Owner'а, маркетологов и т.д., а не пытаться заставить тюленя пахать поле.
К сожалению статья выглядит неправдоподобной. По пунктам:
1. "Мы сжигаем деньги инвесторов" - внезапно оказалось? А до этого не сжигали? Вообще это модель работы стартапов, а у компании судя по описанию уже есть работающий продукт, раз даже платежный модуль для него сделали, и вообще компания давно работает.
2. "Компания серьезно меняла свою бизнес-модель, и скорость вывода продуктов на рынок стала жизненно важной" - и ни слова об этой бизнес-модели и причинах ее изменения. Вот так жила-была компания, зарабатывала деньги и внезапно решила поменять бизнес-модель. Причем на такую, при которой даже платежные модули не нужно тестировать.
3. Несколько раз упоминалось о том, что фиксы и рефакторинг будет потом. Что мешало сразу спросить: "Когда потом?" и написать тут свои выводы? Потому что одно дело если у СТО (который вообще-то технический директор, и должен понимать что полгода-год такого кодинга и дальше никаких "быстро в продакшен" не будет, потому что 9 женщин не родят ребенка за месяц) есть конкретные сроки и план, например: "Нам нужно в течение полугода вывести продукт на рынок и показать рост, после чего мы переходим в спокойный режим и выделяем одну неделю в месяц на рефакторинг и лучшую архитектуру". А если же он просто говорит "потом-потом", то очевидно что никакого плана у него нет, и нужно честно это признать.
4. Автор принимает за аксиому что "бизнесу нужно быстрее", даже не анализируя - действительно это нужно или кто-то решил себе бонусов заработать. Понятно что это не его работа, но это позволит ответить на вопрос "С кем я работаю", ведь это важно программисту.
Отличная статья!
Недавно отказался работать в компании, которая добавляет в спринт задачи после начала спринта и считает это нормальным.
А эти "лучшие умы" точно с нами в одной комнате? Потому что есть подозрение что ее запускали так же, как и Stadia - не проанализировали предыдущие проекты, не улучшили в них ничего и тупо сделали плюс-минус тоже, наступив на те же грабли. В итоге Google+ загнулся, потому что пользователи не смогли ответить на вопрос: "А зачем мне еще одна такая же социальная сеть?".
Статья понравилась. К сожалению ей не хватает конкретных примеров правильной и неправильной интерпретации основных принципов Agile, в формате "Этот принцип поняли неправильно, сделали так, это привело к такому провалу - а вот здесь поняли правильно, сделали так - и это привело к такому результату". Например: в одном стартапе не стали делать документацию, и в итоге, когда они начали расширятся после успеха MVP, из-за того, что новые сотрудники не могли быстро вникнуть в проект, второй этап длился в 2 раза дольше запланированного. А в другом стартапе ввели правило - после передачи задачи в тестирование разработчик не переключается на другую, а садиться и пишет по ней документацию, начиная с самых важных и критических частей. И это даже почти не сдвинуло сроки выхода MVP, потому что когда задача возвращалась из тестирования, разработчик был в контексте и быстро правил баги. А вот второй этап разработки после релиза они сделали почти вовремя, потому что новые разработчики смогли быстро влиться в проект благодаря документации.
На мой взгляд отсутствие таких примеров как раз одна из причин, почему Agile выродился до ритуалов - Agile Manifesto - это лозунги, а персоналу нужны подробные инструкции что и как делать, иначе им банально не на что опереться, интуитивно они не понимают что за лозунгами стоит. А раз подробных инструкций нет, они начинают фокусироваться на то, что есть, на том, что они могут сделать - то есть на ритуалах.
Германия предлагает беженцам оплату квартиры, медицинской страховки и 550 евро в месяц на жизнь, которых хватает не только на еду, но и на одежду и т.д. Не говоря уже о перспективах для тех, кто выучит язык.
А потом сотрудники уходят в курьеры, таксисты и контрактники, и внезапно демотивация начинает играть роль. А если ломается в условиях санкций дорогой станок, который уже не могут отремонтировать специалисты из-за рубежа, то остается один вариант - мужик, который работал с ним последние 10 лет. Но тут внезапно он уходит на 150к, потому что руководство "не может ему повысить зарплату со 100к до 120к, бюджета нет". И миллионы убытков. В мирное время их бы никто не заметил, а сейчас, когда они множатся - упс.
По сравнению с количеством молодежи, которая идет в курьеры и таксисты, количество выбирающих завод скажем так сильно меньше.
Большое количество людей не продумывают свою жизнь. Я в свое время очень удивился, когда понял, сколько людей хотят после школы просто найти работу и жить в свое удовольствие в свободное время, и не задаются вопросами: "От какой работы я буду получать удовольствие?", "Что конкретно я хочу делать?", "Как мне в этом заработать?".
Поэтому часто продавцы и т.д. не отчаявшиеся, а скорее зазомбированные.
Пример с курьерами, таксистами, сейчас добавились сотрудники пунктов выдачи очень показателен - ведь зарплату им платят агрегаторы, которые просчитав экономическую модель поняли, что чем больше людей - тем больше денег.
Проблема в неудачном термине. Вы же сами описали, что на самом деле это значит: "Оцени объективно что у тебя есть сейчас, какие у тебя есть ресурсы для достижения цели и уже отталкиваясь от этого строй план достижения цели - в том числе план как получить тех ресурсы, которых у тебя не хватает". Или так важно найти одно слово, которым можно выразить это предложение?
Дело в том, что этот совет бесполезен без второй части - "не пытайся быть другим". То есть человеку говорят "будь самим собой" когда он неудачно пытается строить из себя другого, например - много и громко шутить в компании, воображая себя успешным стендапером, когда большинство его шуток вызывают испанский стыд.
Редколлегия не должна ничего перепечатывать, написано же - их задача проверить статью, чтобы не допустить публикации неправды. Из-за тщательности проверки у журнала такой высокий рейтинг, и по сути за это и платят люди, которые хотят статью опубликовать, 4к - за проверку. Эффективные же менеджеры решили что "пусть лохи платят 4к за то, а мы будем быстренько статьи проверять частично с помощью ИИ, и заработаем тонну бабла".
Статья - констатация очевидных фактов без реальных примеров реализации для рекламы Телеграм-канала. Сразу минус.
Если кому-то из ваших сотрудников нужен коллективный контроль, то перестаньте нанимать людей из школы, берите уже взрослых.
Проверка эмоционального состояния ненависти к дебильным созвонам.
Замерил - чем меньше созвонов - тем больше производительность.
Даже пароль вспомнил, чтобы прокоментировать. По порядку:
1. "можно поставить цель: «Увеличить количество заполненных анкет на сайте в два раза» " - вроде очевидно, что ставить ее нужно не команде разработчиков, а как минимум Product Owner'у? Или вы из тех, кто нанимает бригаду строителей и говорит "постройте мне классное офисное здание, чтобы хотелось арендовать в нем офис. И сами придумайте план и т.д., в общем сделайте всю работу архитектора и маркетологов". Причем таких команд разработчиков - единицы, и стоят они столько, что вам точно не хватит денег.
2. "Если нет целей" - а зачем вы вообще начинаете проект без целей?
3. " Ответственность за успех разделяется" - как конкретно она разделяется? Разработчики получат долю прибыли? Премии? Или вы из тех, кто думает, что "программировать - это легко, и они не должны за это получать такие бабки, поэтому нагрузим их еще остальным"?
4. "Клиент, ожидая помощи от команды, не сформулировал цели" - если клиент настолько беспомощный, что не в состоянии В СВОЕМ ПРОЕКТЕ, который он по определению должен понимать лучше всех, определить очевидные приоритеты, то нехер на команду разработки перекладывать ответственность.
5. "Правильная цель должна быть конкретна, измерима, достижима, релевантна и привязана ко времени " - а еще остался бизнес, который не способен, пусть и с подсказками ПМа, это сформулировать?
Резюме: статья выглядит как очередная попытка не умеющего в управление переложить свою работу на исполнителей без дополнительной оплаты. И каждый раз эта идея терпит крах, потому что люди в разработку идут не для того, чтобы заниматься задачами управления и маркетинга, а потому что им нравится программировать/тестировать/дизайнить согласно поставленным задачам за нормальные деньги. А клиенту, если он не может сам разобраться со своими целями и т.д., нужно нанять Product Owner'а, маркетологов и т.д., а не пытаться заставить тюленя пахать поле.