Comments 24
Хорошая статья. Хотя бы потому, что во время прочтения мне пришла мысль по поводу того как улучшить один из процессов у себя в отделе. Попадись мне что-то подобное несколько месяцев назад, было бы еще круче.
Огромное спасибо за статью!
На мой взгляд, слишком много «воды» и общих фраз, весьма далеких, по крайней мере, от моей реальности. Я понимаю, что «усредненный посетитель хабра» работает как минимум в многотысячном энтерпрайзе, с миллиардными оборотами и доходами, в командах по 100 человек. Весьма возможно, что рассуждения, показавшиеся мне «водянистыми» и далекими от реальной жизни, в подобных компаниях жизненно необходимы и полезны, не буду спорить.
По моему же опыту работы в маленьких (до ста человек), но успешных стартапах (с десятками миллионов $ годовой прибыли или сотнями миллионов $ финальной продажной цены), я бы заметил, что основная роль тим-лида, с точки зрения команды, это защита интересов команды, а с точки зрения топ-менеджмента — поддержание сроков проекта в приемлемых нормах.
Интересы команды заключаются в том, чтобы поменьше и не слишком напряженно работать (да, увы, помимо гиков и «мальчиков-ударников», у обыкновенных разработчиков есть семьи, хобби и жизнь вне офиса). Интересы топ-менеджмента заключаются в том, чтобы не слишком разочаровать заказчиков сроками внедрения must have «фичи».
Попробую описать типичную ситуацию и роль тим-лидов в ней: крупному заказчику потребовалась абсолютно новая «фича», требующая серьезных изменений как в backend, так и в middleware (по сути, нужно было писать новый сервер, а в клиентских middleware поддержку нового протокола).
Chairman и CTO собирают совещание тимлидов и архитектора, и дискутируют о возможных реализациях (о сложности, времени и т.п.). Тут есть очень важный момент: реализовать можно так, чтобы клиентская часть была проще (но тогда, естественно, серверная часть становится намного сложнее), либо наоборот. Вот тут начинается борьба тимлидов; чем тимлид победит, тот и круче (с точки зрения его команды). Понятно, что я тут немного утрирую, и все происходит вовсе не так уж просто — тимлиды проводят совещания с командой и ищут правильные аргументы в поддержку своего решения (то бишь, выгодного для команды).
То есть, главная «внешняя» (по отношению к команде) функция тимлида заключается в разумном отстаивании интересов команды.
«Внутренняя» же функция заключается в правильном планировании времени и ресурсов (то бишь разработчиков). Непосредственно кодировать тимлиду особенно нет времени, очень много его уходит на всевозможные митинги и «утряски» неполадок, но… Хорошо программировать и кодировать тимлид просто обязан уметь; также он должен быть «универсалом», и разбираться как минимум на экспертном уровне для какой-то одной платформы (если мы говорим о мультиплатформенном решении), и на уровне «неплохо знаком» с остальными, чтобы, в случае showstopper-ов включиться в рядовую работу команды. От хорошего исполнения именно «внутренней» функции и зависит «хорошесть» тимлида для топ-менеджмента.
Еще в обязанности тимлида у нас входило слежение за правильным выполнением технологий программирования, «утрясание» конфликтов с QA (очень неприятная задача!), «пробивание» нужных команде «фич» в проект, а также «выбивание» дополнительных ресурсов (как человеческих, так и материальных — хотя ими, формально, он не должен был заниматься).
P.S. Но, вообще-то, с точки зрения ответственности за принимаемые решения хуже приходится PM-у (или, в нашем случае, CTO).
По моему же опыту работы в маленьких (до ста человек), но успешных стартапах (с десятками миллионов $ годовой прибыли или сотнями миллионов $ финальной продажной цены), я бы заметил, что основная роль тим-лида, с точки зрения команды, это защита интересов команды, а с точки зрения топ-менеджмента — поддержание сроков проекта в приемлемых нормах.
Интересы команды заключаются в том, чтобы поменьше и не слишком напряженно работать (да, увы, помимо гиков и «мальчиков-ударников», у обыкновенных разработчиков есть семьи, хобби и жизнь вне офиса). Интересы топ-менеджмента заключаются в том, чтобы не слишком разочаровать заказчиков сроками внедрения must have «фичи».
Попробую описать типичную ситуацию и роль тим-лидов в ней: крупному заказчику потребовалась абсолютно новая «фича», требующая серьезных изменений как в backend, так и в middleware (по сути, нужно было писать новый сервер, а в клиентских middleware поддержку нового протокола).
Chairman и CTO собирают совещание тимлидов и архитектора, и дискутируют о возможных реализациях (о сложности, времени и т.п.). Тут есть очень важный момент: реализовать можно так, чтобы клиентская часть была проще (но тогда, естественно, серверная часть становится намного сложнее), либо наоборот. Вот тут начинается борьба тимлидов; чем тимлид победит, тот и круче (с точки зрения его команды). Понятно, что я тут немного утрирую, и все происходит вовсе не так уж просто — тимлиды проводят совещания с командой и ищут правильные аргументы в поддержку своего решения (то бишь, выгодного для команды).
То есть, главная «внешняя» (по отношению к команде) функция тимлида заключается в разумном отстаивании интересов команды.
«Внутренняя» же функция заключается в правильном планировании времени и ресурсов (то бишь разработчиков). Непосредственно кодировать тимлиду особенно нет времени, очень много его уходит на всевозможные митинги и «утряски» неполадок, но… Хорошо программировать и кодировать тимлид просто обязан уметь; также он должен быть «универсалом», и разбираться как минимум на экспертном уровне для какой-то одной платформы (если мы говорим о мультиплатформенном решении), и на уровне «неплохо знаком» с остальными, чтобы, в случае showstopper-ов включиться в рядовую работу команды. От хорошего исполнения именно «внутренней» функции и зависит «хорошесть» тимлида для топ-менеджмента.
Еще в обязанности тимлида у нас входило слежение за правильным выполнением технологий программирования, «утрясание» конфликтов с QA (очень неприятная задача!), «пробивание» нужных команде «фич» в проект, а также «выбивание» дополнительных ресурсов (как человеческих, так и материальных — хотя ими, формально, он не должен был заниматься).
P.S. Но, вообще-то, с точки зрения ответственности за принимаемые решения хуже приходится PM-у (или, в нашем случае, CTO).
Отстаивание интересов отдела — так себе стратегия. При этом компания превращается в такое подобие Киевской Руси времён Татаро-Монгольского нашествия — куча грызущихся между собой «княжеств», не способных объединиться против общего «врага».
Да, наверное это идеальная среда для «просто работников», которые приходят просиживать штаны от зарплаты и до обеда. Как говорится «солдат спит — служба идёт», и чем меньше работы — тем лучше.
При таком «менджменте» специалистам разных отделов чтобы добиться чего-то оказывается проще договорится о чём-то втихую между собой, чем через своих и чужих лидов-«опекунов». Потому что последние костьми лягут, чтобы не делать никакую работу и замотают вопрос на бесконечных митингах и боксу по переписке.
Продукт при таком управлении превращается в говно. На жалобы пользователей следует ответ «это ответственность не моего отдела» с бесконечными переводами стрелок. Качество продукта никого не волнует, потому что каждый отдел решает не общие задачи, а пилит что-то интересное им, да и в конце концов «есть семьи, хобби и жизнь вне офиса».
Всё это хоть как-то работает с использованием ресурса «дюли от начальства», когда лидам-«опекунам» откровенно дают по заднице и заставляют «работу работать».
Это не моя фантазия, а реальный опыт на некотором этапе (с точки зрения специалиста, не начальника).
Да, наверное это идеальная среда для «просто работников», которые приходят просиживать штаны от зарплаты и до обеда. Как говорится «солдат спит — служба идёт», и чем меньше работы — тем лучше.
При таком «менджменте» специалистам разных отделов чтобы добиться чего-то оказывается проще договорится о чём-то втихую между собой, чем через своих и чужих лидов-«опекунов». Потому что последние костьми лягут, чтобы не делать никакую работу и замотают вопрос на бесконечных митингах и боксу по переписке.
Продукт при таком управлении превращается в говно. На жалобы пользователей следует ответ «это ответственность не моего отдела» с бесконечными переводами стрелок. Качество продукта никого не волнует, потому что каждый отдел решает не общие задачи, а пилит что-то интересное им, да и в конце концов «есть семьи, хобби и жизнь вне офиса».
Всё это хоть как-то работает с использованием ресурса «дюли от начальства», когда лидам-«опекунам» откровенно дают по заднице и заставляют «работу работать».
Это не моя фантазия, а реальный опыт на некотором этапе (с точки зрения специалиста, не начальника).
dendron, все, вышеизложенное мной — не некий «сферический конь в вакууме», а сокращенное обобщение личного опыта работы в чрезвычайно успешном американском стартапе, основанном одной легендарной (в узких кругах) личностью (если вам так интересно, могу отписать в личку). Я не знаком с вашим опытом (и заранее написал «отмазку» про многобиллионные энтерпрайзы), но, уверяю вас, стартап с продуктом был продан за сумму, за которую в России продаются считанные компании, и принес «отцам-основателям» 500% процентную прибыль.
Не было никаких «княжеств», да и не могло быть: ведь все employee были заинтересованы в acquisition, и, могу вас заверить, не прогадали (хотя, конечно, целью было не IPO, и это сказалось на результатах для обычных сотрудников — ну, так слишком много никто и не обещал!). Просто в результате хорошего профессионального менеджмента, проводимого CEO, «войны» тимлидов приводили к выработке оптимального по балансу и времени решения, которое удовлетворяло всех.
Возможно, тут сыграло роль иная, в отличие от российской, пресловутая «ментальность» — ну, не принято у нас «кадык вырывать», «мамой клясться», и испытывать неиллюзорную ненависть к оппоненту!
Продукт в «говно» никогда не превращался; ответственность команд за showstoppers — это вещь предельно ясная и дискуссий тут быть не может, всегда ясно, чей «косяк».
А профессионалы, замечу, это далеко не всегда «гики-работоголики»; одним из лучших профессионалов, которых я знал (как раз по этой работе), как ни странно, была мать троих детей из Индии (и, замечу, очень хорошая мать). Да, она не любила overtime, но, благодаря хорошим и профессиональным teamleads у нас их практически и не было! Зато девушка (преимущества моего возраста в том, что я женщин среднего возраста всегда называю девушками :) ) очень быстро (даже, парадоксально быстро) «въезжала в тему», и даже сумела перебороть (под моим чутким руководством) страсть к «индусскому говнокодированию», что вообще не поддается объяснению!
Не было никаких «княжеств», да и не могло быть: ведь все employee были заинтересованы в acquisition, и, могу вас заверить, не прогадали (хотя, конечно, целью было не IPO, и это сказалось на результатах для обычных сотрудников — ну, так слишком много никто и не обещал!). Просто в результате хорошего профессионального менеджмента, проводимого CEO, «войны» тимлидов приводили к выработке оптимального по балансу и времени решения, которое удовлетворяло всех.
Возможно, тут сыграло роль иная, в отличие от российской, пресловутая «ментальность» — ну, не принято у нас «кадык вырывать», «мамой клясться», и испытывать неиллюзорную ненависть к оппоненту!
Продукт в «говно» никогда не превращался; ответственность команд за showstoppers — это вещь предельно ясная и дискуссий тут быть не может, всегда ясно, чей «косяк».
А профессионалы, замечу, это далеко не всегда «гики-работоголики»; одним из лучших профессионалов, которых я знал (как раз по этой работе), как ни странно, была мать троих детей из Индии (и, замечу, очень хорошая мать). Да, она не любила overtime, но, благодаря хорошим и профессиональным teamleads у нас их практически и не было! Зато девушка (преимущества моего возраста в том, что я женщин среднего возраста всегда называю девушками :) ) очень быстро (даже, парадоксально быстро) «въезжала в тему», и даже сумела перебороть (под моим чутким руководством) страсть к «индусскому говнокодированию», что вообще не поддается объяснению!
>Продукт в «говно» никогда не превращался; ответственность команд за showstoppers — это вещь предельно ясная и дискуссий тут быть не может, всегда ясно, чей «косяк».
Ну здорово что у вас всё так ясно было. Но явные косяки (за которые будет бо-бо) люди и так стараются не делать. А чаще бывает что «косяк» находится в зоне ответственности между отделами, вида «один не доделал, второй не додумал». И начинается бесконечный срач, потому что никто не хочет за других работу делать. Или хуже — из-за размытия ответственности и общей атмосферы «моя хата с краю» все предпочитают просто закрыть глаза на проблему (пока не придёт «мотивация» от начальства сверху).
>ведь все employee были заинтересованы в acquisition
А вот эта самая загадочная часть. Вроде бы совершенно никакой мотивации нет в успехе общего дела (потому что нет этого общего дела, есть только «я тут сижу, примус починяю»). Возможно это действительно некая ментальность или атмосфера в той конкретной компании. Потому что тут явное противоречие с остальной идеологией.
>А профессионалы, замечу, это далеко не всегда «гики-работоголики»
Я этого не утверждал. Есть разница между тем переживает человек за конечный результат своей работы, или просто просиживает офисные часы (занимается саморазвитием/пробует интересные технологии/втайне пишет своё приложение — выберите сами). А перерабатывать или нет — каждый выбирает сам.
Ну здорово что у вас всё так ясно было. Но явные косяки (за которые будет бо-бо) люди и так стараются не делать. А чаще бывает что «косяк» находится в зоне ответственности между отделами, вида «один не доделал, второй не додумал». И начинается бесконечный срач, потому что никто не хочет за других работу делать. Или хуже — из-за размытия ответственности и общей атмосферы «моя хата с краю» все предпочитают просто закрыть глаза на проблему (пока не придёт «мотивация» от начальства сверху).
>ведь все employee были заинтересованы в acquisition
А вот эта самая загадочная часть. Вроде бы совершенно никакой мотивации нет в успехе общего дела (потому что нет этого общего дела, есть только «я тут сижу, примус починяю»). Возможно это действительно некая ментальность или атмосфера в той конкретной компании. Потому что тут явное противоречие с остальной идеологией.
>А профессионалы, замечу, это далеко не всегда «гики-работоголики»
Я этого не утверждал. Есть разница между тем переживает человек за конечный результат своей работы, или просто просиживает офисные часы (занимается саморазвитием/пробует интересные технологии/втайне пишет своё приложение — выберите сами). А перерабатывать или нет — каждый выбирает сам.
А чаще бывает что «косяк» находится в зоне ответственности между отделами, вида «один не доделал, второй не додумал».
Вы говорите об архитектурных ошибках; у нас, благодаря правильной архитектуре и менеджменту, таких ошибок не было. То есть, ошибки практически всегда четко классифицировались, и никакого «срача» не возникало (за 6 лет, лишь пару-тройку раз QA неправильно классифицировал ошибку, но, опять-таки, все разрешалось очень просто, без «срачей»). Никакого «размытия ответственности» не было, да и не могло быть.
А вот эта самая загадочная часть. Вроде бы совершенно никакой мотивации нет
Ничего загадочного нет, все очень просто! Вы, видимо, не знакомы с западными реалиями, но тут дела обстоят так: обычно, в крупные и известные компании профессионал идет в расчете на карьерный рост, шансов на это в большой компании намного больше, чем в маленькой. Небольшие компании, а в особенности — стартапы, чтобы «заманить» хорошего специалиста, должны использовать всевозможные «пряники», как-то высокие зарплаты и «благие обещания» (обычно «благие обещания» изначально оцениваются дешевле). То бишь «мотивация» обеспечивается договором, в котором employee гарантируется либо определенная часть shares в случае IPO (это, как правило, очень сильная «замануха», сродни «золотой лихорадки», в случае успеха можно действительно получить очень много), либо определенный фиксированный бонус в случае продажи компании.
А перерабатывать или нет — каждый выбирает сам.
Гмм, вы или очень молоды, или очень неопытны (или и то, и другое вместе). Иным я столь странное утверждение объяснить не могу.
>То бишь «мотивация» обеспечивается договором, в котором employee гарантируется либо определенная часть shares в случае IPO
Вся ясно, мы с вами в разных мирах вращаемся.
>Гмм, вы или очень молоды, или очень неопытны (или и то, и другое вместе). Иным я столь странное утверждение объяснить не могу.
Для вас странное, для меня — нет. В любом случае, хамить не следовало бы. За сим разговор с вами прекращаю.
Вся ясно, мы с вами в разных мирах вращаемся.
>Гмм, вы или очень молоды, или очень неопытны (или и то, и другое вместе). Иным я столь странное утверждение объяснить не могу.
Для вас странное, для меня — нет. В любом случае, хамить не следовало бы. За сим разговор с вами прекращаю.
Дорогой dendron, не нужно быть Шерлоком Холмсом, чтобы определить молодость и отсутствие жизненного опыта в ваших незрелых суждениях! Но в одном вы ошибаетесь — констатация того факта, что вы молоды и неопытны — это не упрёк, а, скорее, комплимент. И зря вы упрекаете меня в каком-то «хамстве» — ведь я не сказал, что ваши бредовые максималистические высказывания обусловлены банальной глупостью? Я всегда думаю о людях хорошо, вот такой я добряк.
Ничего, подрастете, поднакопите опыта, обзаведетесь (дай Бог!) семьей — и, наконец, поймете, как мир устроен :)
Ничего, подрастете, поднакопите опыта, обзаведетесь (дай Бог!) семьей — и, наконец, поймете, как мир устроен :)
Ремарки на тему "вы еще молоды и неопытны" в данном случае прозвучали в поучительном тоне. Вот dendron и возмутился.
Полностью с вами согласен, что возможность выбора переработок есть только пока нет семьи и детей. И если кому-то не хватает восьми часового рабочего дня для того что бы окончательно вымотаться к вечеру, то ему есть куда расти в плане повышения продуктивности.
Уважаемый arcman, я бы сказал даже больше: если у неопытного юноши нет вариантов, «куда податься вечером», кроме как сидеть и «тупить» в офисе над кодом, ему стоит серьёзно задуматься над своей жизнью! Тут не о «продуктивности» нужно думать, а о репродуктивности! (вот такой вот родился каламбур :) )
каждый отдел решает не общие задачи, а пилит что-то интересное имИдеально.
Да, большое спасибо!
Статья развернутая, но имхо для человека, которому дали эту роль придется в его конкретных условиях строить свою команду. Я как-то смотрел презентацию, в которой в довольно убедительной манере рассказывалось про процесс эволюции тим лидера. Начинается с получения роли и иногда желания поруководить и заканчивается полным доверием со стороны команды. Это занимает время, приходит с опытом, а иногда не приходит вообще. Процессы… Они могут вызывать отторжение. Неопытный тим лид может попытаться их жестко навязать. Это может стать проблемой. Согласен с автором в том, что бизнес рулит и все хорошо что хорошо для него в итоге. Процессы так процессы. Или их отсутсвие и анархия. Заказчик самый главный. По поводу защиты интересов команды, тут главное не перестараться и объяснить в случае чего заказчику, что мол больше мы делать не можем. Честно объяснить.
Как правило, тимлид выбирается из наиболее опытных и уважаемых членов команды (никогда не слышал о позиции тимлида, по крайней мере, на US маркете — обычно из «сопоставимых» величин ищут или PM-а, или архитектора). Из этого следует, что вопрос доверия команды, как правило, просто не возникает.
Опять-таки, выше я описал типичные задачи тимлида; уж поверьте мне, если вам выпадет подобная роль, то следование подобным принципам даст вам как уважение команды, так и благодарность менеджмента.
Абстрактные советы для «сферического тимлида в вакууме», типа «продумайте систему обучения сотрудников» (зачем их обучать? Вы набрали newbies на проект?!), или «настройте процессы работы в отделе. При этом максимально их задокументируйте» (какие «процессы»??? И зачем «документировать» что-то, лишенное сущности? Кому вы покажете эту бюрократию, когда вас вышвырнут за не исполнение прямых обязанностей?! Адвокату? Ни один адвокат за такое просто не возьмется!).
В общем, статья практически ни о чем. Хотите быть хорошим тимлидом — отстаивайте интересы команды, и не подводите менеджмент по срокам. Все!
Опять-таки, выше я описал типичные задачи тимлида; уж поверьте мне, если вам выпадет подобная роль, то следование подобным принципам даст вам как уважение команды, так и благодарность менеджмента.
Абстрактные советы для «сферического тимлида в вакууме», типа «продумайте систему обучения сотрудников» (зачем их обучать? Вы набрали newbies на проект?!), или «настройте процессы работы в отделе. При этом максимально их задокументируйте» (какие «процессы»??? И зачем «документировать» что-то, лишенное сущности? Кому вы покажете эту бюрократию, когда вас вышвырнут за не исполнение прямых обязанностей?! Адвокату? Ни один адвокат за такое просто не возьмется!).
В общем, статья практически ни о чем. Хотите быть хорошим тимлидом — отстаивайте интересы команды, и не подводите менеджмент по срокам. Все!
Детская статья с детской логикой, графиками и смешными картинками.
Мастер Йода ожидаем тут был, и вот он тут. Лидинг он такой.
Я конечно понимаю, что не совсем по теме, но помнит кто, из какой игры красные человечки в самом начале статьи? :3
Настройте процессы работы в отделе. При этом максимально их задокументируйте.
Продумайте систему обучения сотрудников.
Настройте правильную систему делегирования различного рода заданий и лишь направляйте и контролируйте их выполнение.
Вступайте в диалог в любой непонятной ситуации. В споре рождается истина. Лишь так вы поймете людей и получите подтверждение, что они понимают вас.
Согласно моему опыту этот список это скорее ряд ошибок, а не полезных практик:
Настройте процессы работы в отделе. При этом максимально их задокументируйте.
Тут возможнвы два случая:
- наиболее вероятно вы стали лидом в существующей коменде. Она ведь как-то работает? и работала. не нужно насаждать "процессы всегда и везде" т.к. получите запредельный уровень сопротивления. Работайте как консультант — присматривайтесь, вносите предложения на рассмотрение самой команде, если они отторгают, значит не понимают зачем это надо, что является вашей проблемой, а не команды. Если вы начинаете документировать процесс, то либо у вас большая текучка и это действительно имеет смысл, либо ваши процессы не очевидны и уложить их в голове 3-4 принципами и 2-3 практивкам невозможно, опять же — вы перегибаете палку с формализмом.
- менее вероятно, что новичка поставили в новую команду к незнакомым ему людям. тут надо не настраивать процессы, а создать и сполить команду хоть как-то выполняя задачи. Периоды Forming и Storming никто не отменял.
Продумайте систему обучения сотрудников.
забавно, что пункт этот второй, а не последний. Помните, что половина ваших сотрудников "ходит протирать штаны до обеда", даже заявляя благие намерения. Если человек не хочет учиться — не надо, если человек хочет учиться — сам научится. Общие рекоммендации по "ты дорастешь до этого уровня и получишь прибавку" вам выдаст сама компания и вам не надо это создавать с ноля. Помните, что все люди разные, у всех разные жизеннные цели и разные цели в компании.
Настройте правильную систему делегирования различного рода заданий и лишь направляйте и контролируйте их выполнение.
вот он, тот пункт, над которым можно и нужно работать бесконечно. самый сложный и самый важный для вас как лида. Только делегируя вы начнете использовать ваше время во благо компании, а не попусту. Читайте про "7 уровней делигирования" и тп модели. "Правильная система делегирования" это вода, вы должны ставить куда более четкие цели, например: 40% критических задач, которыми раньше занимался только я теперь должны делать другие люди. Цель "Учитесь искать метрики и измерять ваши результаты" мне в своё время помогла куда больше, чем что либо еще. И самое главное "правильного делегирования" нет и не будет. Есть то, что работает лично у вас с вышей командой.
Вступайте в диалог в любой непонятной ситуации. В споре рождается истина. Лишь так вы поймете людей и получите подтверждение, что они понимают вас.
Кажется, что очень правильный совет, но дьявол в деталях. Именно с такой идеей я подходил к решению всех возможных не понятных ситуаций и только спустя пару лет осознал, что стал "митинг манагером", проводящий по 3-4 часа в день в митинг румах. Многие проблемы могут решиться и без вас, не реигруйте на все сразу — у вас нет столько времени. Дайте проблемам немного настояться, чтобы появилось четкое понимание их причин. Давайте возможность людям самим решать свои конфликты и подключайтесь только на 2-3 уровене эскалации. Проблема пришла сверху? Не надо звать в митинг рум ваших менеджеров/команду и искать решение. Подумайте, посторайтесь сами принять какое-то решение и поделитесь своим видением с менеджментом тем же емейлом, с подписью "я бы рекомендовал личную/skype встречу для уточнения деталей" на первое время. Помогайте вашему руководству, а не отнимайте у него время.
Не забывайте — вы Лид и вы берете на себя ответственность. Не дайте ответственности вас сожрать и не впадайте от страха в состояние контроля всего и вся — это раздражает людей и вы потратите много ненужного времени. Ваша задача состоит в том, чтобы ваши люди работали продуктивно, а не "максимально продуктивно". То же касается и вас.
Sign up to leave a comment.
Как стать тимлидом и не взорваться