Пиздеж, в норм компаниях это тандем который дополняет друг друга. Не разу кодер не возмущался что я баг нашёл или указал что тут можно сделать по другому. С другой стороны я ни разу не писал что эй ты мудень что за говнокод, понимая что человек вложил труд и время, а то что его подгоняли или просто шит хепенс он не виноват.
раскрыть ветку (31)
Работала в 3 крупных компаниях и везде был успешный тандем между разрабом и тестером, максимум подколы, а вот менеджеры - настоящий корень зла. Гораздо правдивее гифка, где разраб и тестер сообща пиздят менеджера, а потом приходит девопс и пиздит всех
раскрыть ветку (23)
раскрыть ветку (20)
Работать нужно в компаниях, где для каждой задачи есть свой квалифицированный персонал. Выше тимлида/техлида/архитектора технические навыки помогут менеджеру если только закрывать бреши в работе за бестолковыми подчененными или самому действовать за границами нормального процесса.
раскрыть ветку (18)
Ну расскажи это большим ИТ компаниям, где менеджеры проходят собеседование на знание основ разработки.
Очень полезно понимать, что делают люди, работой которых ты управляешь.
ещё комментарии
Я видал достаточно больших ИТ-компаний и процессы там зачастую дрянные с большими утечками времени-денег на всякую фигню. Почитайте про тот же яндекс, где любые дыры затыкают рандомными людьми. Такое сплошь и рядом, как в РФ, так и за рубежом.
Очень полезно понимать, что делают люди, работой которых ты управляешь.
Если повторить эту мантру пять раз, она станет убедительнее? Я тоже тогда попробую: если ты не решаешь технических вопросов, то технические навыки не пригодятся.
раскрыть ветку (16)
Ну вот видишь. Ты читал про компании, а я в них работал. Не все там так плохо.
Объясни человеку без технических навыков, почему вот такое на вид сложное приложение делать месяц, а вот это совсем фигню на вид - год. Придется долго разжевывать прописные истины. Если менеджер сам их понимает - жить становится легче.
Я работал с разными менеджерами: которые не шарят и не парятся, которые не шарят и пытаются учиться, которые бывшие разработчики. С первыми работа - ад, поскольку они не могут ничем процессу помочь, то начинается бесцельный микроменеджемент и попытки показать себя важной птицей. Вторые - самое частое явление, жить можно, но с ними приходится как с детьми, постоянно рассказывать все, периодически бывают недопонимания. С последней группой - смешанный опыт, один был прям богоподобный, второй был той еще гнидой "да я бы сам этот проект за неделю сделал, вы че тут уже месяц копаетесь?!" - но он просто был человек-редиска.
Короче, опыт разработки у менеджера очень приветствуется.
раскрыть ветку (15)
Ты читал про компании, а я в них работал.
Откуда такие выводы? Вы просто рандомный чувак с пикабу, к какому авторитету тут можно апеллировать? Вы тыкаете незнакомцу, посему вполне можете натягивать потолки или водить такси. (Ничего не имею против этих профессий, их представители общаются с большим количеством клиентов и их наверняка запаривает спрашивать разрешения переходить на "ты")
Объясни человеку без технических навыков, почему вот такое на вид сложное приложение делать месяц, а вот это совсем фигню на вид - год.
Менеджеру не важно почему так, важно какие есть выходы, сколько это будет стоить и как это может отразиться на результате. Цифры для менеджера будут генерировать специально обученные люди, оспаривать или ревьюить их - предельно глупо для человека, который знает заведомо меньше специалистов. Уж ebanoe.it от историй про таких чудо-управленцев ломится.
раскрыть ветку (14)
В интернете на развлекательном ресурсе требовать себя величать на Вы - странно.
Тираду про таксистов я не понял, к чему это вообще было.
А последний абзац говорит, что о роли менеджера в команде разработчиков ты не очень много знаешь, ну или хороших просто не видел. Они вместе с тимлидом ответственны за организацию рабочего процесса, связь проекта с другими проектами компании. Они должны хорошо себе представлять, что и как работает. Ему не нужно объяснять, что мы не можем просто так интегрироваться с тем другим сервисом потому что у нас grpc, а у тех rest api, ему не надо читать лекцию об этом.
раскрыть ветку (13)
В интернете на развлекательном ресурсе требовать себя величать на Вы - странно.
Элементарная вежливость, не более того.
Они вместе с тимлидом ответственны за организацию рабочего процесса
Большие компании, говорите?) Хех.
Ему не нужно объяснять, что мы не можем просто так интегрироваться с тем другим сервисом потому что у нас grpc, а у тех rest api, ему не надо читать лекцию об этом.
Что ему даст сакральное знание того, что есть grpc и чем оно отличается от rest api? От этого переделывать дешевле станет или подпирание костылями альтернативного транспорта меньше начнет влиять на архитектуру в долгосрочной перспективе?
Если он въедливый, но ленивый и не верит своим тех.спецам, то он скорее всего плохой менеджер, но совсем не потому, что не рубит в технических аспектах.
раскрыть ветку (12)
Ну да, я смешал мелкие и крупные компании. И оттого лишь более важно в мелких компаниях толкового менеджера иметь.
Если ты взаимодействие менеджера с разработчиками хочешь свести исключительно к "через сколько дней будет готово вот это? Через 7? Отлично, жду результат через 7 дней", то ничего хорошего из этого не выйдет.
раскрыть ветку (11)
Если ты взаимодействие менеджера с разработчиками хочешь свести исключительно к "через сколько дней будет готово вот это? Через 7? Отлично, жду результат через 7 дней"
Ну, как бы, аджайлы и скрам, роли людей в них, различные уровни планирования и отчетности, контроль качества. Это всё появилось раньше, чем настолько массовое IT, какое оно есть сейчас.
раскрыть ветку (10)
В том и дело, что agile появился как понимание того, что все меняется и планы вечно меняются. Agile - быстрая реакция на изменения и корректирование плана постоянно. И менеджер также принимает в этом роль, он может быть вовлечен во всякие планирования и ретроспективы. Не понимать, о чем говорят там люди - ну так себе польза тогда.
раскрыть ветку (9)
Что ему даст сакральное знание того, что есть grpc и чем оно отличается от rest api? От этого переделывать дешевле станет или подпирание костылями альтернативного транспорта меньше начнет влиять на архитектуру в долгосрочной перспективе?
-----
Скажем, линейный менеджер не принимает участия в скрам-процессе вообще. PO - только в тех митингах, которые касаются изменений в ТЗ и приёмке работы. Скрам-мастеру вообще все равно, кто там какой код пишет, главное - регламентировать взаимодействие между членами професса. Кому не пофиг - это технические специалисты, вроде архитектора, тех.лида, программистов (да, отдельного тимлида в скраме не предусмотрено). По желанию, эксперты могут быть привлечены со стороны заказчика.
раскрыть ветку (8)
Отвечая на первый вопрос - когда команда обсуждает, что можно сделать и как, менеджер будет стоять и лупать глазками. Можно ему попробовать объяснить что-то там про протоколы, про разные интерфейсы. Он в целом что-то поймет.
Если подходить ко всем ролям формально, то может ты и прав, менеджеры могут жить и не тужить. Но выполнение минимальных требований своей роли - это не сказать чтобы достаточно для профессионала. Если тебе надо настроить работу в молокозаводе, то ты можешь узнать про формальные роли сотрудников, про процессы, настроить KPI и регулярные отчеты. И ты будешь ровно тем эффективным менеджером и тысяч историй. Чтобы действительно сделать работу качественно, круто бы понимать, как и что люди делают.
В некоторых компаниях новые разработчики проводят день с тех поддержкой, помогая. Зачем? Да чтобы понимать, что действительно хотят пользователи, как они думают и с какими проблемами сталкиваются. Хотя формально, конечно, это им нафиг не надо.
раскрыть ветку (7)
когда команда обсуждает, что можно сделать и как, менеджер будет стоять и лупать глазками.
Вообще без разницы, как это выглядит) Он может не ходить на такие митинги. Когда команда родит вопросы и к ТЗ, тогда и пообщаются.
В некоторых компаниях новые разработчики проводят день с тех поддержкой, помогая.
Как бы разработчики изучают проект, который они будут разрабатывать) А техподдержка - кладезь юзкейсов. Если бы они туда менеджеров любых уровней подсаживали и уборщиц из БЦ - вот была бы сказка (= А что, пусть знают, с чем где и ради чего работают!
раскрыть ветку (6)
раскрыть ветку (5)
Вообще, я постарался довести логическую нестыковку до абсурда с помощью уборщицы. Жаль, но видимо получилось недостаточно явно)
Мое мнение, что знания лишними не бывают никогда. Но считать это решающим преимуществом, скажем, при найме не по профилю - тоже было бы неправильно.
раскрыть ветку (4)
А я где-то говорил, что это решающее преимущество? Я говорил, что с менеджерами, которые не знают, но стараются, жить можно. Но менеджер, который ещё и разбирается что к чему - круче.
раскрыть ветку (3)
Вы (или не вы, кто там был тред-стартером) утверждали, что работать нужно идти туда, где манагеры - из тех.специалистов выросли. Мой поинт в том, что идти нужно туда, где процессы нормальные. Это ведь про решающее преимущество (выбора места работы), верно?
раскрыть ветку (2)
Ну не обязательно, на самом деле. В стартапах есть свой шарм - свобода действий, простор для креатива, но нормальных процессов, конечно, нет. Так что это все по вкусу. Но при прочих равных, я бы предпочел менеджера со знанием основ, хотя это и не критично.
раскрыть ветку (1)
Качество процессов и техническая подкованность менеджеров - в общем-то ортогональные понятия.
хотя это и не критично.
ОК, на том тогда и порешим.
ещё комментарии
Это не мастхев, но полезно. Тут не в опыте разработчикам дело, а в достаточном понимании матчасти.
раскрыть ветку (2)
В плохой компании наоборот, где нет общего продукта, там каждый делает "своё" дело, а тот, кто вмешивается - враг. А плохих компаний не так и мало. В хорошей компании и заказчик не мудак, такие разговоры сразу пресекаются, иначе хорошего продукта не выпустить.
раскрыть ветку (1)
Ну, если тестер, разраб и продакт_менеджер работают ровно на зарплату, то наверно да - человек человеку волк
Это уже дань традиции, в стиле 'где нашел, как нашел, какого хуя нашел'
Тестер экономит время прогера, прогер даёт работу тестеру - это нормально
Это же 'ха-ха-ха свежий оригинальный ни разу не заезженный мемчик о том, что дев что-то делает, а тестер это ломает и они не любят друг друга'
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору