Я стараюсь максимально подробно рассказать о компании, о командах, на какой проект человек пойдет, с какими технологиями надо работать. Недавно у меня спрашивали критерии повышения, рассказываю как ращу людей (в качестве примера можете прочитать статью: habr.com/ru/post/457430). Показываю как у нас устроен процесс, показываю прямо на схемах и т.д. И в конце собеседования у меня есть рассказ о компании, команде, процессе, проекте и уже в конце я прошу соискателя справить меня вопросы, которые ему интересны.
На мой взгляд, это дает понять, что все то, что он сказал, это не пустой звук, а так и есть. У меня есть один знакомый, он работает в крупной компании, и с процессами ему сказали, что всё ок. Он пришел и понял, что там болото. В итоге он этим занимается (он Team Lead), а руководству пофиг. Просто эти вопросы помогут выявить явные проблемы, а дальше уже кандидату решать готов он туда идти или нет. Например, я один раз пришел в компанию, где было всё печально, но мне честно сказали, что плохо. Я сам для себя решил, что готов прийти и сделать хорошо. Конечно, это была не должность простого инженера.
Если вы хотите попасть в хорошее место, чтобы вы развивались и росли, то какие-то вопросы на мой взгляд задавать стоит. А зачем устраиваться к рабовладельцу? Есть гораздо лучше места. Единственное, с чем соглашусь, мест, где растят людей, конечно, мало.
Да, вы правы, всё надо делать осмысленно, а не бездумно их задавать. Я не предлагаю задавать их HR, на большинство они и не ответят. Многие вопросы надо задавать непосредственно руководителю.
Понятно, что правды никто не скажет, но либо вам дадут адекватный ответ о причинах, либо нет. Если нет, то можно ждать что угодно. Я знаю случай, когда человек устроился на работу, руководитель не давал обратную связь, а потом сказал, что не сработались.
Я когда-то давно работал в компании, которая занималась хостингом, помимо этого, у них было направление gamedev, на сайте ни слова не было сказано об этом. Также много компаний, которые запускают IT-проекты, и не всегда это связано напрямую с её деятельностью. Ну и стартапы никто не отменял.
Я просто хотел показать, как это выглядит со стороны по всей индустрии, и надеялся, что кто-то задумается, что они делают. Когда кому-то пришло в голову что-то внедрить, или он это делает не потому что команде лучше, а потому что он так решил. Менеджеры не ходят вниз и не стараются решить настоящую боль, даже не пытаются разобраться. А метрики внедряют от того, что они не понимают, зачастую они бесполезны. Например, люди внедрили воркфлоу в Джире, чтобы процессы стали прозрачны. Но так настроили, что менеджеры, как ходили отвлекали разработчиков, так и ходят. И ещё 5 раз поменяли, но не понимают, что не так и что люди снизу стонут.
Я не пытался предложить какое-то решение и не предлагал выкинуть весь накопленный опыт, я хотел показать, как люди неправильно применяют разные методики, и заставить их задуматься. И что красивые картинки и графики и результат — это две совершенно разные вещи.
Смотрите, в Trello у вас есть доска, но вы не можете разделить, колонки, например, на do и done, также нет возможности поставить WIP-limits. По горизонтали тоже поделить не получится. Кроме того, в Trello нельзя добавлять удобные правила, которые срабатывают, когда вы перетаскиваете карточку из одной колонки в другую. Также там нет инструментов, чтобы строить спектральную и накопительную диаграммы. В Kaiten это все есть.
В компании, в которой я это делал, было так. Бизнесом я называю разные юнит единицы: основатель, отдел продаж, отдел логистики, отдел по работе с партнерами и т.д. Не было роли выделенного архитектора, были техлиды направлений. Были аналитики, которые занимались описанием фич, также они занимались и выясняли, что можно сделать для пользователя. Даже мне приходилось выполнять роль продукт-оунера. Отдельной роли продукт оунера не было.
Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы. И простой нашего узкого места равен простою всей системы. То есть мы должны эффективно распределять задачи. Например, бекенд может 10, а фронт 5. Если мы завалим всех работой, то на фронтендеров вывалится столько задач, сколько они не смогут отработать. А если мы эти задачи будем копить, то может получиться так, что эти фичи за время ожидания потеряют актуальность. Хотя можно было бы за это время и код отрефакторить, и баги пофиксить.
У меня на это ушло чуть меньше двух лет. Набивали шишки, экспериментировали и т.д. Сейчас, мне кажется, сделал бы за год или чуть больше (в тех же условиях). Совсем быстро не получится, это утопия.
Таких тренингов не знаю, но посоветовал бы послушать отдельных людей, которые на мой взгляд говорят здравые вещи. У каждого можно что-то почерпнуть. На Youtube можно найти их выступления на различных конференциях:
Александр Зиза — управление командами, личный рост и т.д.
Алексей Пименов — выстраивание процессов, ajile и т.д.
Максим Дорофеев — прокрастинолог
Я считаю, что стоит развивать такие компетенции: технические навыки, управление командами, эффективное выстраивание процессов и управление проектами. Важно научиться смотреть на разработку, как на бизнес. Но на самом деле главное придерживаться одного простого принципа: я его называю «думай головой», он обычно всегда помогает =)
Если говорить про конкретный список литературы, то я его вижу примерно так:
Программирование:
«Чистый код» Роберт Мартин
«Банда четырех» Эрих Гамма, Джон Влисидис, Ричард Хелм, Ральф Джонсон
«Искусство программирования» Дональд Кнут
«Совершенный код» Стив Макконнелл
Управление:
«Трудно быть боссом» Хилл Линда
«Лидер и племя» Дэйв Логан, Джон Кинг и Хэли Фишер-Райт
«Как привести дела в порядок» Дэвид Аллен
Выстраивание процессов:
«Scrum. Революционный метод управления проектами» Джефф Сазерленд
«Канбан. Альтернативный путь в Agile» Дэвид Андерсон
«Критическая цепь», «Цель» и другие Элияху Голдратт
«Черный лебедь», «Рискуя собственной шкурой» и другие Нассим Талеб
Для меня главным было то, что смог сильнее влиять на проект. То есть у тебя есть ресурсы, и ты с их помощью можешь не просто взять и написать код, а помочь сделать целый продукт, который может принести реальную пользу в гораздо больших масштабах. По сути реализовать свои амбиции. И делать то, за что не было бы стыдно.
На мой взгляд, это дает понять, что все то, что он сказал, это не пустой звук, а так и есть. У меня есть один знакомый, он работает в крупной компании, и с процессами ему сказали, что всё ок. Он пришел и понял, что там болото. В итоге он этим занимается (он Team Lead), а руководству пофиг. Просто эти вопросы помогут выявить явные проблемы, а дальше уже кандидату решать готов он туда идти или нет. Например, я один раз пришел в компанию, где было всё печально, но мне честно сказали, что плохо. Я сам для себя решил, что готов прийти и сделать хорошо. Конечно, это была не должность простого инженера.
Александр Зиза — управление командами, личный рост и т.д.
Алексей Пименов — выстраивание процессов, ajile и т.д.
Максим Дорофеев — прокрастинолог
Если говорить про конкретный список литературы, то я его вижу примерно так:
Программирование:
Управление:
Выстраивание процессов:
Для понимания бизнеса: