В одном предложении два противоречия:1) Делать меньше, но важного, автоматически исключает решение менее важных проблем — вы всегда загружены решением только важных проблем.2) Решение важных проблем не снижает нагрузку, а лишь изменяет приоритеты. Вы всё равно остаетесь загруженными решением важных проблем.
Противоречий нет.
Когда находишься в состоянии, где у тебя куча острых проблем со всех сторон - они все жрут силы и время.
Решая самые важные из них, вы освобождаете себе энергию, с которой вы уже можете приступить к решению менее острых и важных. Более того, сосредоточившись на них, отбросив всё, что можно - вы решаете эти самые острые и важные проблемы эффективнее - а значит, быстрее выходите из состояния шторма.
Ваш пример с бэклогом во-первых, не про критическую ситуацию, а про обычную работу. А во-вторых - у вас странная трактовка "важности" и "сырости".
> Если действовать по-моему, то будут исправлены 7 багов Р1, 2 бага Р2 и 1 баг Р3. И этот вариант хуже. Почему у багов P3 меньше приоритет? Потому что они влияют на меньшее число пользователей и при этом менее критичные. А значит - да, надо фиксить баги с высшим приоритетом.
Если баг долго не решается - его приоритет может вырасти и стать P1 или P2. Если же он лежит в P3, но при этом сделать его важнее, чем P1 - значит у вас бэклог с плохо проставленными приоритетами, либо же просто не обновлёнными.
> Понятно, что успех продукта будет выше у того производителя, который принимает во внимание обратную связь от пользователей, а не у того, кто практически полностью игнорирует её
Успех будет выше у того продукта, который ориентируется на количество и важность этой обратной связи. Или у того, который будет разумно расходовать деньги, грамотно балансируя между идеальностью и нужностью рынку
Вот пустой инбокс и прочий GTD я так и не смог в свою жизнь внедрить, в моём случае ресурсов требует больше, чем пользы приносит. А все остальные пункты дико плюсую)
Говоря про Цеттелькастен - скорее нет, там всё-таки суть во внутренних связях. Вот свой Цеттелькастен пытаюсь вести всё-таки в электронном виде, в обсидиане, тут с бумажными карточками правда неудобно :) Но это база знаний, так что тема несколько другая
На содержание отвёл один разворот. Дневник небольшой (просто в Ташкенте маленький выбор), 80 листов. До этого тоже были такого размера
Переполнения содержания не было - но, наверное, можно пару раз взять небольшие дневники, а потом если что будет понятно, нужно ли больше отводить. В конце-концов можно на корке дописать
Блоки остальные не заканчиваются, тут подробнее напишу
Чем гениальна нумерация страниц - блоки можно продолжать, под них в целом не отводится место заранее. Как выглядит процесс:
- Появилась новая коллекция у меня - начал писать в первой свободной строке (под ежедневник я всё равно забиваю страницы, но это специфический блок) - Когда начал писать - прикинул много ли надо страниц (обычно немного, 1-6) - Если место закончилось, или надо потом вернуться - начинаю в новом месте, в содержание дописываю доп.страницы (как у меня на картинке - 40-48 (первая итерация), 60 (начал писать дальше) - (Продвинутый уровень) В уголке 48й страницы пишу "(стр.60)", на 60й "(стр. 48)" - так можно одну коллекцию листать не возвращаясь к содержанию
Звучит немного сложно, но на практике - это просто, быстро привыкаешь. Надеюсь, объяснил :)
Туше, ваша формулировка классная и правильная. Я сознательно в статье упростил её, оставив только разрез про управление командой, поскольку речь шла именно о проблеме связанной с работой с командой, тем более что большинство руководителей в разработке чаще всего занимается именно этим. Неявно вышло, наверное, в следующий раз постараюсь сформулировать чище.
Но у нас тут спор возник относительно жизненных приоритетов руководителя, и стоит ли ему работать нянькой, если уж он управляет командой. На мой взгляд - нет :)
Как правило, проблема не в руководителях самих, а в том, что их выставили руководить, а как это делать - не объяснили и не обучили. Вот и начинают думать, что они должны быть умнее всех и всех контролировать, потому что не понимают, что ещё делать-то и боятся облажаться.
> Какие задачи остаются у руководителя кроме сервисных и подбора персонала, где вообще его роль в скрамгайде? В скраме нет одного руководителя, там эта роль дробится между несколькими членами команды.
> Ладно, фиг с ним со скрамом. Матричная организация предприятия — проектом (людьми и процессами) рулит руководитель проекта. А руководитель всех этих разработчиков — опять сервисные функции и защита от злого и несправедливого проджекта.
Я вроде и говорил, что руководитель - выполняет сервисную роль - организовывает работу команды необходимым для бизнеса образом. Не вижу противоречий (разве что против истории со "злым проджектом")
> это действительно вообще не задача руководителя. Аналитик, архитектор, но не руководитель. Зависит от. Где-то для этого есть выделенные роли, где-то этим занимается руководитель. Зависит от размеров, специфики, и вообще отрасли, где это происходит.
Я не видел общепринятых метрик, но пару раз встречал использование такой же, как у Вкусвилла. Вкусвилл считает это так: 1. Берём зарплаты всех сотрудников компании 2. Считаем, какой процент от зарплат уходит на зарплаты руководителей
Идея в том, что чем автономнее и свободнее работают люди, тем меньше нужно руководителей, что бы управлять процессом.
Насколько важно учитывать такую категорию, как "стоимость управления" в работе тимлида/руководителя
Думаю это интересно знать, но в практике - не очень полезно. Всё-таки это вопрос C-level управленцев. Другой вопрос, что понимая, за счёт чего Вкусвилл этого добился - можно строить лучшие процессы у себя в команде.
Ну если бы отрасли соответствовали полностью - это была бы одна и та же отрасль, разве не так?)
Конечно, есть разный набор параметров, но ни один из них не является чем-то совершенно уникальным - а значит с проблемами могли сталкиваться отрасли, в которых есть тот или иной схожий набор параметров - значит оттуда можно натаскать себе решений проблем.
У врачей вон есть не только обьём обучения, но и сложность задач, и высокий стресс. У адуиторов не только предметная область, но и работа удалённо. Пересечений больше одного со многими отраслями
В IT почти каждый занимается подражанием, натаскиванием и копированием чужих идей и решений
Это не только в IT так, мы в целом входим в постмодернисткую эпоху, когда количество уже придуманного крайне велико.
> Я бы сказал что хватит учиться, пора практиковать Ну практикуем-то мы каждый день. Но действительно, часто не хватает осмысления нашей деятельности. А ещё - мы временами пытаемся решить проблемы, которые уже решены в других отраслях - а значит, можно взять чужой опыт и использовать его - это дешевле и менее болезненно, чем набивать все шишки самим)
Врач, конечно, не может масштабировать себя. Но есть инженер, который может спроектировать устройство, которое потом будут выпускать годами. Архитектор может спроектировать типовой дом, которым будут застраивать дачные посёлки по всей стране, если не миру. Построенная нефтяная скважина будет питать множество производств.
Да и с врачом всё не так однозначно. Биолог может произвести лекарство, которое будут принимать больше людей, чем пользуется гуглом, например.
Разумеется, у нас есть своя специфика - у нас это делать проще и дешевле, чем в вышеописанных примерах. Но тем не менее, такое влияние на мир - оно тоже встречается и в других отраслях.
Кмк, многие, кого назвают джунами - даже не джуны, а интерны. Джун всё-таки младший специалист, но уже обладающий определёнными навыками в профессии, а вот интерн - человек, который только впервые приходит на работу и стажируется.
Сегодня, когда роль университетов падает, ты уже не стажируешься во время учёбы, ты осваиваешь какой-то навык и идёшь работать. Но по сути, по квалификации - ты - интерн.
А у нас обычно это смешивают в кучу, и из-за этого люди, которые только прошли какие-то курсы и вышли на первую работу именуются так же, как люди, которые 4 года отучились, делая в это время какие-то сайд-проекты и подрабатывая.
Почему же не индустрия достижений? Вполне также в нашей отрасли люди пытаются получить различного рода достижения. К примеру получать различные сертификаты от вендоров сдавая экзамены, или скажем выступать на каких то конференциях
Так я об этом и пишу :) Это исскуственное, оно не нужно. У проф спортсмена нет "обычной работы", вся его карьера заточена на получение достижений - не получил - отправляйся в утиль с поломанным телом. У нас не так - ты можешь всю жизнь спокойно ходить на работу и зарабатывать деньги
Абстрактный пример на дровосеках. Вот рубят они топорами лес. А тут на рынке появляется бензопила
Это экстремальный пример. Дровосеки по вечерам не сидят и не делают сайд-проекты по рубке лесов для портфлоио. Если происходит революция в индустрии - им придётся обучаться, но я ведь не о том.
А вот не абстрактный пример, очень большое количество сайтов написано с использованием jquery, но при этом сейчас он нужен все меньше. Надо ли развиваться фронтендеру чтобы уйти с jquery или можно оставаться на нем? Работая каждый день с jquery он ведь не будет развиваться во все эти нужные сейчас реактивные технологии?
У него есть несколько путей. Во-первых, он может просто сменить работу на ту, где внедряют новые технологии и учиться там. Во-вторых, он может выучить новый фреймворк. В-третьих - может остаться и поддерживать старое легаси, которого в мире очень много.
В любом случае, для того, чтоб оставаться востребованным - ему не обязаельно сидеть и постоянно учить все новые выходящие фреймворки - он может спокойно жить своей жизнью.
Вы правы когда говорите что люди не обязаны развиваться, но развиваться обязаны все те кто хочет быть лучшим среди остальных
Да, но не всем надо быть лучшим, о том и речь :)
Я понимаю ваши аргументы, но мы как будто говорим немного про разное. Я за то, чтоб индустрия не навязывала людям бесконечную гонку.
И я уже почти подготовил следующую статью, где попробую рассказать, как можно всё-таки развиваться, но не жертвуя ради этого всем временем. Наверное, это и будет ответ на ваши мысли
Противоречий нет.
Когда находишься в состоянии, где у тебя куча острых проблем со всех сторон - они все жрут силы и время.
Решая самые важные из них, вы освобождаете себе энергию, с которой вы уже можете приступить к решению менее острых и важных. Более того, сосредоточившись на них, отбросив всё, что можно - вы решаете эти самые острые и важные проблемы эффективнее - а значит, быстрее выходите из состояния шторма.
Ваш пример с бэклогом во-первых, не про критическую ситуацию, а про обычную работу. А во-вторых - у вас странная трактовка "важности" и "сырости".
> Если действовать по-моему, то будут исправлены 7 багов Р1, 2 бага Р2 и 1 баг Р3.
И этот вариант хуже. Почему у багов P3 меньше приоритет? Потому что они влияют на меньшее число пользователей и при этом менее критичные. А значит - да, надо фиксить баги с высшим приоритетом.
Если баг долго не решается - его приоритет может вырасти и стать P1 или P2. Если же он лежит в P3, но при этом сделать его важнее, чем P1 - значит у вас бэклог с плохо проставленными приоритетами, либо же просто не обновлёнными.
> Понятно, что успех продукта будет выше у того производителя, который принимает во внимание обратную связь от пользователей, а не у того, кто практически полностью игнорирует её
Успех будет выше у того продукта, который ориентируется на количество и важность этой обратной связи. Или у того, который будет разумно расходовать деньги, грамотно балансируя между идеальностью и нужностью рынку
Вот пустой инбокс и прочий GTD я так и не смог в свою жизнь внедрить, в моём случае ресурсов требует больше, чем пользы приносит. А все остальные пункты дико плюсую)
Найс, хороший подход. А блокнот не слишком огромный выходит, таскать такое с собой не сложно?
В 20 веке всё-таки и интернет, и мир были сильно другими. В нынешней жизни слишком мало оффлайна стало
Да в целом ничего. Единственное - если добавлять в середину, то нумерация ломается. В конец легко добавлять
Говоря про Цеттелькастен - скорее нет, там всё-таки суть во внутренних связях. Вот свой Цеттелькастен пытаюсь вести всё-таки в электронном виде, в обсидиане, тут с бумажными карточками правда неудобно :) Но это база знаний, так что тема несколько другая
На содержание отвёл один разворот. Дневник небольшой (просто в Ташкенте маленький выбор), 80 листов. До этого тоже были такого размера
Переполнения содержания не было - но, наверное, можно пару раз взять небольшие дневники, а потом если что будет понятно, нужно ли больше отводить. В конце-концов можно на корке дописать
Блоки остальные не заканчиваются, тут подробнее напишу
Чем гениальна нумерация страниц - блоки можно продолжать, под них в целом не отводится место заранее. Как выглядит процесс:
- Появилась новая коллекция у меня - начал писать в первой свободной строке (под ежедневник я всё равно забиваю страницы, но это специфический блок)
- Когда начал писать - прикинул много ли надо страниц (обычно немного, 1-6)
- Если место закончилось, или надо потом вернуться - начинаю в новом месте, в содержание дописываю доп.страницы (как у меня на картинке - 40-48 (первая итерация), 60 (начал писать дальше)
- (Продвинутый уровень) В уголке 48й страницы пишу "(стр.60)", на 60й "(стр. 48)" - так можно одну коллекцию листать не возвращаясь к содержанию
Звучит немного сложно, но на практике - это просто, быстро привыкаешь. Надеюсь, объяснил :)
Туше, ваша формулировка классная и правильная. Я сознательно в статье упростил её, оставив только разрез про управление командой, поскольку речь шла именно о проблеме связанной с работой с командой, тем более что большинство руководителей в разработке чаще всего занимается именно этим. Неявно вышло, наверное, в следующий раз постараюсь сформулировать чище.
Но у нас тут спор возник относительно жизненных приоритетов руководителя, и стоит ли ему работать нянькой, если уж он управляет командой. На мой взгляд - нет :)
Как правило, проблема не в руководителях самих, а в том, что их выставили руководить, а как это делать - не объяснили и не обучили. Вот и начинают думать, что они должны быть умнее всех и всех контролировать, потому что не понимают, что ещё делать-то и боятся облажаться.
Так а в чём вопрос-то?
> Какие задачи остаются у руководителя кроме сервисных и подбора персонала, где вообще его роль в скрамгайде?
В скраме нет одного руководителя, там эта роль дробится между несколькими членами команды.
> Ладно, фиг с ним со скрамом. Матричная организация предприятия — проектом (людьми и процессами) рулит руководитель проекта. А руководитель всех этих разработчиков — опять сервисные функции и защита от злого и несправедливого проджекта.
Я вроде и говорил, что руководитель - выполняет сервисную роль - организовывает работу команды необходимым для бизнеса образом. Не вижу противоречий (разве что против истории со "злым проджектом")
> это действительно вообще не задача руководителя. Аналитик, архитектор, но не руководитель.
Зависит от. Где-то для этого есть выделенные роли, где-то этим занимается руководитель. Зависит от размеров, специфики, и вообще отрасли, где это происходит.
Я в статье описывал всё же не жизненные приоритеты конкретного человека, а роль руководителя и его профессиональные задачи.
А какие, на ваш взгляд задачи руководителя?
Ну ссылки правда никто не открывает, но можно же текстом описание с цифрами класненькое вставить.
Плюс кое-где есть культура cover letter - там тоже круто подсветить для конкретной работы соотвествующие достижения
Я не видел общепринятых метрик, но пару раз встречал использование такой же, как у Вкусвилла. Вкусвилл считает это так:
1. Берём зарплаты всех сотрудников компании
2. Считаем, какой процент от зарплат уходит на зарплаты руководителей
Идея в том, что чем автономнее и свободнее работают люди, тем меньше нужно руководителей, что бы управлять процессом.
Думаю это интересно знать, но в практике - не очень полезно. Всё-таки это вопрос C-level управленцев. Другой вопрос, что понимая, за счёт чего Вкусвилл этого добился - можно строить лучшие процессы у себя в команде.
Ну если бы отрасли соответствовали полностью - это была бы одна и та же отрасль, разве не так?)
Конечно, есть разный набор параметров, но ни один из них не является чем-то совершенно уникальным - а значит с проблемами могли сталкиваться отрасли, в которых есть тот или иной схожий набор параметров - значит оттуда можно натаскать себе решений проблем.
У врачей вон есть не только обьём обучения, но и сложность задач, и высокий стресс. У адуиторов не только предметная область, но и работа удалённо. Пересечений больше одного со многими отраслями
Это не только в IT так, мы в целом входим в постмодернисткую эпоху, когда количество уже придуманного крайне велико.
> Я бы сказал что хватит учиться, пора практиковать
Ну практикуем-то мы каждый день. Но действительно, часто не хватает осмысления нашей деятельности. А ещё - мы временами пытаемся решить проблемы, которые уже решены в других отраслях - а значит, можно взять чужой опыт и использовать его - это дешевле и менее болезненно, чем набивать все шишки самим)
Я бы сказал, что это тоже не совсем так.
Врач, конечно, не может масштабировать себя. Но есть инженер, который может спроектировать устройство, которое потом будут выпускать годами. Архитектор может спроектировать типовой дом, которым будут застраивать дачные посёлки по всей стране, если не миру. Построенная нефтяная скважина будет питать множество производств.
Да и с врачом всё не так однозначно. Биолог может произвести лекарство, которое будут принимать больше людей, чем пользуется гуглом, например.
Разумеется, у нас есть своя специфика - у нас это делать проще и дешевле, чем в вышеописанных примерах. Но тем не менее, такое влияние на мир - оно тоже встречается и в других отраслях.
Кмк, многие, кого назвают джунами - даже не джуны, а интерны. Джун всё-таки младший специалист, но уже обладающий определёнными навыками в профессии, а вот интерн - человек, который только впервые приходит на работу и стажируется.
Сегодня, когда роль университетов падает, ты уже не стажируешься во время учёбы, ты осваиваешь какой-то навык и идёшь работать. Но по сути, по квалификации - ты - интерн.
А у нас обычно это смешивают в кучу, и из-за этого люди, которые только прошли какие-то курсы и вышли на первую работу именуются так же, как люди, которые 4 года отучились, делая в это время какие-то сайд-проекты и подрабатывая.
Так это же и есть прямой путь к депрессии :(
Если постоянные переживания есть - то это знак, что стоит поработать с психологом
Так я об этом и пишу :) Это исскуственное, оно не нужно. У проф спортсмена нет "обычной работы", вся его карьера заточена на получение достижений - не получил - отправляйся в утиль с поломанным телом. У нас не так - ты можешь всю жизнь спокойно ходить на работу и зарабатывать деньги
Это экстремальный пример. Дровосеки по вечерам не сидят и не делают сайд-проекты по рубке лесов для портфлоио. Если происходит революция в индустрии - им придётся обучаться, но я ведь не о том.
У него есть несколько путей. Во-первых, он может просто сменить работу на ту, где внедряют новые технологии и учиться там. Во-вторых, он может выучить новый фреймворк. В-третьих - может остаться и поддерживать старое легаси, которого в мире очень много.
В любом случае, для того, чтоб оставаться востребованным - ему не обязаельно сидеть и постоянно учить все новые выходящие фреймворки - он может спокойно жить своей жизнью.
Да, но не всем надо быть лучшим, о том и речь :)
Я понимаю ваши аргументы, но мы как будто говорим немного про разное. Я за то, чтоб индустрия не навязывала людям бесконечную гонку.
И я уже почти подготовил следующую статью, где попробую рассказать, как можно всё-таки развиваться, но не жертвуя ради этого всем временем. Наверное, это и будет ответ на ваши мысли