Мы так и делаем. Общепринятые стандарты меняются редко и я не особенно на это надеюсь. Я ж не говорю, что мы отсеиваем всех, у кого в резюме таблица скилов. Как раз наоборот, если есть намеки и отдельные проблески — мы зовем человека и с ним разговариваем, конечно.
Но согласитесь, всегда можно попробовать немножко изменить статус кво. Эта статья такая слаааабенькая попытка.
Я не знаю, может в Беларуси так звезды встали. Но подавляющее большинство резюме с мейлру ужасны. За все время мы взяли на работу только одного человека, который послал резюме с мейлру. Может, это выполняется не во всех временных зонах.
Я сделал хитрее. На каждого кандидата добавляю карточку на доске и аттачу к ней резюме. Получается очень удобно проводить кандидатов по всему флоу cl.ly/image/0m2k0G2A0T3P (и резюме под рукой)
У нас в свое время была такая проблема. Ретроспективы выявляли несколько проблем и мы намечали 8-10 экшн айтемов. Через 2 недели собирались снова, опять намечали несколько и частенько брали незаконченные из предыдущих. Короче накапливались они. А накапливались по той причине, что проблемы были достаточно фундаментальными (автоматизация тестов) и решения их вообще занимают месяцы, а не дни.
Так что как пару простых советов я предлагаю
1 — фокусироваться на 1-2 главных проблем и пытаться их решить
2 — разбивать решения этих проблем на как можно более мелкие задачи, которые можно закончить за пару недель.
Ну и в целом, так как скрам ничего не говорит о формате ретроспектив, хорошо бы узнать побольше о системном мышлении и поучиться решать проблемы с помощью всяких полунаучных подходов, типа диаграммы ишикавы, статистики и тп. Демминг об этом отлично писал с примерами, хотя бы в книжке Выход из кризиса.
Видимо с годами у меня теряется способность выражать свои мысли. Поясню, к чему я все это писал. В области разработки ПО много проблем и областей, где есть явные пробелы. Я попытаюсь перечислить их тут кратко.
— Знание предментой области
— craftsmanship
— умение решать проблемы (системное мышление, научный подход)
— разработка сложных систем в больших масштабах
— UX
— быстрая обратная связь
Все носятся со скрамом и внедряют его, решая только последнюю проблему и затрагивая только последнюю область. Остальному уделяется гораздо меньше внимания. Это не то чтобы плохо. Но скрам далего не сильвер балит. И вообще не факт, что лучший фреймворк для софтверных команд. Взгляд на скрам Книберга мне вполне симпатичен, но к сожалению большинство при внедрении скрама смотрят на него как на достаточную вещь, а он всего лишь необходимая вещь при трансформации процессов из вотерфольных в что-то более гибкое.
Аналогия с шахматами неплохая, мне понравилась. Примерно про это я и говорил
«Благодаря внешней простоте процесса, Scrum показался очень привлекательным для многих управленцев. Но для неопытной команды без внешних консультантов улучшить свой процесс на основе Scrum достаточно сложно. Это трудоемкий и долгий процесс, который может занять годы.»
1. Мотивации совершенно недо статочно, чтобы сделать правильную вещь. Нужно еще очень много чего. Понимание потребностей пользователей, умение наладить с пользователями контакт и выяснить, что же для них на самом деле сработает (причем прямые ответы на такие вопросы редко нужно воплощать в жизнь). Соответственно нужны процессы, которые помогают узнавать, правильную ли вещь мы делаем. Скрам молчит по этому поводу.
2. Практически каждый человек в чем-то талантлив. Я так понимаю, мы сужаем тему до талантливых разработчиков/тестировщиков/дизайнеров. Довольно общая фраза. В меру сложные продукты можно делать без особого таланта. Чтобы делать прорывные продукты пожалуй без таланта не обойтись. Ну и талант еще нужно правильно развить. Скрам ничего про это не говорит, а принимает по умолчанию.
3. Самый важный пункт. Вы не добавили ничего нового к статье этим пунктом. Я уже говорил, что скрам дает быстрый фидбек (очевидно, благодаря спринтам). Ну да, дает. Вы уверены, что не существует других способов ускорения фидбека? Конечно существуют. Их достаточно много, включая прототипирование, юзабилити тесты, и вообще переход на безитерационную разработку типа канбан.
Итак мы пожалуй согласились, что скрам можно отнести только к категории инструментов, который помогает ускоряться (и то весьма органиченно, за счет ускорения обратной связи). И никак не решает самые важные проблемы — правильные вещи правильно. Ведь скорость на мой взгляд менее важна.
Но согласитесь, всегда можно попробовать немножко изменить статус кво. Эта статья такая слаааабенькая попытка.
Я не хочу креатива, я хочу нормальный рассказ о себе, о достижениях, о проблемах и их решениях.
Мне гораздо приятнее получить письмо из 30 строк по делу, чем резюме на 3 листа со всяких шлаком. Об этом я напишу во второй части.
Хаха. Забавное замечание. Отрегулируйте пожалуйста весь земной шар.
Так что как пару простых советов я предлагаю
1 — фокусироваться на 1-2 главных проблем и пытаться их решить
2 — разбивать решения этих проблем на как можно более мелкие задачи, которые можно закончить за пару недель.
Ну и в целом, так как скрам ничего не говорит о формате ретроспектив, хорошо бы узнать побольше о системном мышлении и поучиться решать проблемы с помощью всяких полунаучных подходов, типа диаграммы ишикавы, статистики и тп. Демминг об этом отлично писал с примерами, хотя бы в книжке Выход из кризиса.
— Знание предментой области
— craftsmanship
— умение решать проблемы (системное мышление, научный подход)
— разработка сложных систем в больших масштабах
— UX
— быстрая обратная связь
Все носятся со скрамом и внедряют его, решая только последнюю проблему и затрагивая только последнюю область. Остальному уделяется гораздо меньше внимания. Это не то чтобы плохо. Но скрам далего не сильвер балит. И вообще не факт, что лучший фреймворк для софтверных команд. Взгляд на скрам Книберга мне вполне симпатичен, но к сожалению большинство при внедрении скрама смотрят на него как на достаточную вещь, а он всего лишь необходимая вещь при трансформации процессов из вотерфольных в что-то более гибкое.
Аналогия с шахматами неплохая, мне понравилась. Примерно про это я и говорил
«Благодаря внешней простоте процесса, Scrum показался очень привлекательным для многих управленцев. Но для неопытной команды без внешних консультантов улучшить свой процесс на основе Scrum достаточно сложно. Это трудоемкий и долгий процесс, который может занять годы.»
1. Мотивации совершенно недо статочно, чтобы сделать правильную вещь. Нужно еще очень много чего. Понимание потребностей пользователей, умение наладить с пользователями контакт и выяснить, что же для них на самом деле сработает (причем прямые ответы на такие вопросы редко нужно воплощать в жизнь). Соответственно нужны процессы, которые помогают узнавать, правильную ли вещь мы делаем. Скрам молчит по этому поводу.
2. Практически каждый человек в чем-то талантлив. Я так понимаю, мы сужаем тему до талантливых разработчиков/тестировщиков/дизайнеров. Довольно общая фраза. В меру сложные продукты можно делать без особого таланта. Чтобы делать прорывные продукты пожалуй без таланта не обойтись. Ну и талант еще нужно правильно развить. Скрам ничего про это не говорит, а принимает по умолчанию.
3. Самый важный пункт. Вы не добавили ничего нового к статье этим пунктом. Я уже говорил, что скрам дает быстрый фидбек (очевидно, благодаря спринтам). Ну да, дает. Вы уверены, что не существует других способов ускорения фидбека? Конечно существуют. Их достаточно много, включая прототипирование, юзабилити тесты, и вообще переход на безитерационную разработку типа канбан.
Итак мы пожалуй согласились, что скрам можно отнести только к категории инструментов, который помогает ускоряться (и то весьма органиченно, за счет ускорения обратной связи). И никак не решает самые важные проблемы — правильные вещи правильно. Ведь скорость на мой взгляд менее важна.