В англоязычном менеджменте есть четыре грейда развития специалиста, которые описываются забавной игрой слов:
1. I don't know what I don't know - Я не знаю что я не знаю.
Это новичок, пришедший с курсов, которому втирали что он теперь супер-пупер спец. Ему кажется что все легко и просто делается и он не видит никаких проблем - он еще не столкнулся со своими пробелами в знании.
2. I know what I don't know - Я знаю что я не знаю.
А теперь вот столкнулся - и пришло понимание, что все его знания покрывают только малую часть, а в остальном, как оказывается - пусто. Здесь он сталкивается с синдромом самозванца и должен найти в себе силы (и получить поддержку), чтобы продолжить учиться и развиваться.
3. I know what I know - Я знаю что я знаю
Поборов синдром самозванца, зрелый специалист может четко и ясно разграничить область своих знаний от незнаний. Он сделает вам прекрасно ту работу, в которой разбирается, но откажется от другой - "не моя специфика, не знаю". Он не боится своих незнаний. Очень многие специалисты здесь останавливаются, т.к. не видят смысла или не могут расти дальше.
4. I don't know what I know - Я не знаю что я знаю.
Это специалисты-кудесники, которые творят чудеса за счет своего глубокого развития в смежных областях и широкого кругозора щелкают задачи на синергии различных своих знаний, не имея внезапно знаний и опыта по поставленной задаче - они говорят удивленно "Надо же, оказывается я знаю кунг-фу и это знаю и могу.
Развитие специалистов по этим стадиям сильно зависит от внешнего окружения и от действий менеджера (руководителя) - как и какими задачами нагружать специалиста, какими способами мотивировать, как реагировать на разные косяки.
Если интересно - погуглите сами по названиям стадий.
Рылся в сети, искал информацию про да-да старт карьеры в ИТ (про тимлидство конкретно) и наткнулся на статью. Показалась интересной! Ссылку оставлю на неё в конце.
Всем привет!
Хотел бы поделиться некоторым количеством мыслей и выводов, которые я сделал, работая на такой непростой должности, как teamlead команды разработки.
Вообще, мой путь в ИТ начинался довольно спонтанно и я бы даже сказал, странно.
Преамбула
Чуть меньше года назад мне в Телеграмме позвонил коллега, с которым мы давно знакомы и который трудится в должности Head of IT в нашей компании. Коллегу зовут Слава.
И у нас состоялся примерно такой разговор:
С: Привет! Как дела? Я: Привет! Всё по-старому, много дел, зашиваемся. Объекты, сроки, люди горят. Жуть, словом! С: Ага, ага, понятно, да, ясно! Слушай, а как к ИТшечке относишься?
Я: Слав, ну, никак! Кибернетика эта ваша! Ничего не понимаю, сложно представить, слабо представляю, кто там работает и чем занимается.
С: Не хотел бы попробовать?
Я: Влезть в 31 год куда-то, где я нихрена не понимаю? Я? Человек у которого сто тысяч дел, вот-вот родится дочь и который работает по 13 часов в день, потому что жалеет подчинённых и пытается им помочь?.. Я: Конечно, давай…
Я думаю, что важно дать небольшое пояснение.
Я довольно давно работаю на существующем и по сей день месте работы. Если ничего не путаю, то порядка 8 лет (надо уточнить в Кадрах будет, кстати). Я пришёл работать сюда… Короче, простым водителем.
Карьера
Шаг 1. Водитель
Ездил от поставщиков на склад, оттуда на объекты, потом в офис, потом к поставщикам и так по кругу до бесконечности.
Именно тогда я понял, что моя сильная сторона, если хотите, талант- это общение и коммуникации, что называется, ртом.
На самых разных уровнях: от вредного охранника, который не увидел пропуск на мою машину и кладовщиков, которые вообще всё перепутали и отдали не тот заказ, до генерального директора, который задаёт мне вопросы по поводу просроченных оплат с нашей стороны (такое бывало, когда контрагент небольшой и генеральный директор занимался и оформлением УПД и прочих СФ) или бухгалтера, который не принимал доверенность из-за того, что я её заполнял при них.
Именно тогда я начал совершенно отчётливо понимать, что почти всегда и почти обо всём можно договариваться с людьми. Важно ловить настроение и понимать, что именно не так в той ситуации, в которой ты оказался. Как можно решить, что сказать, с какой интонацией, с какой скоростью и серьёзностью надо проговорить какие-то вещи, чтобы ситуация решилась в мою пользу.
Тезис №1
Надо учиться не использовать инструменты, приёмы, уловки или какие-то ещё инфоцыганные ухищрения, а контролировать себя, слышать людей и строить диалог таким образом, чтобы твой оппонент начал видеть в тебе не оппонента, а союзника (извиняюсь за высокопарные выражения. Так чуть проще понять, что имею в виду).
Мы тут, вообще‑то, не меряемся красноречием, а проблемы решаем.
и тут же
Тезис № 2
Избитая фраза «Признавать свои ошибки» как‑будто потеряла хоть какой‑то привкус прикладного применения в современном мире. Я считаю, что надо признавать чужие в первую очередь. Очень полезная штука как в жизни, так и в работе. Пусть даже это признание будет понарошку. Что‑то вроде: «Да, да! Ничего страшного, что вы не подготовили товар к отгрузке (Страшно! Очень! Это критичеки важно! Время 17:00, и я на другом конце города должен быть до 18:00! В пятницу!).
Но тут Ваши нервы и попытки ускорить бедного раздолбая‑кладовщика ещё больше введут его в ступор, он начнёт тупить совсем уж бессовестно и сильно, и Вы не получите ничего вообще.
Отвлёкся! Так вот!
На такой работе я проработал примерно полтора года и мне стало тесновато. Пообщался с начальником и…мы взяли в штат другого водителя, а я уселся на нашем маленьком складе наводить порядок.
Шаг 2. Начальник склада
Сначала было скучновато без такого потока взаимодействий, но потом я нашёл прелесть в самом процессе наведения порядка. Я придумал учёт (1С у нас тогда на складе не было, она была только в бухгалтерии) с помощью онлайн таблиц. Изучал формулы, их прикладное применение и примерно через пару‑тройку месяцев склад был идеален. Не боюсь тут себя перехвалить, потому что получилось на самом деле хорошо.
У нас появились транзитные ячейки, «удалённые склады», излишки. Я снимал остатки и закупки формировали свои запросы, снимая сначала остатки со склада.
Всё стало предсказуемо и очень прозрачно. Любой сотрудник в любой момент времени был в курсе, что же у нас там по ТМЦ (товарно‑материальные ценности). И...мне стало тесновато!
Пообщался с начальником и…мы взяли в штат другого кладовщика/начальника склада. Я же уселся уже в кресло помощника менеджера по снабжению.
Тезис №3
Надо общаться. Ну, надо общаться. И с боссами тоже! Вернее, с ними в первую очередь. По самым разным вопросам и на разные темы, но это надо. Но то ли мы устроены как‑то так, что «поближе к кухне‑подальше от начальства», то ли у нас какие‑то базовые настройки такие, что нам, ну, вот никак вообще неудобно (плохо, нелепо, не к месту) подойти и задать вопросы, которые интересуют. Может «так принято»...
Чтобы было проще браться за вопросы, которые Вас касаются напрямую, как мне кажется, надо перестать думать так, как Вы думали, расшориться и посмотреть вот с какой стороны.
Вставочка- немного про разговоры с боссом
У Вас есть работа. Работа- это когда Вы меняете своё время на что-то. Чаще всего на деньги 🙂. То есть, продаёте.
Эта метрика ясна, понятна.
Теперь взгляните не как сотрудник, а как собственник (или кто у Вас приниматель решений по вопросам Level UP-ов и прочих денег). Верно! Собственник покупает у Вас Ваше время. Все хотят сделать это как можно более выгодно, не правда ли?
Решение, которое я для вывел в сухом остатке- это общаться.
Важно не выпрашивать, а взвешенно и уверенно говорить, что Вы научились делать, что хотели бы делать в дальнейшем.
Также, не между делом, а прямо озвучить, что это нужно Вам не только для карьерных успехов, а для увеличения доходов. Да, прям для денег. В моей карьере такие разговоры помогали расставить точки над i.
Помните, кстати, что любой Ваш босс- это такой же человек (почти всегда). И он тоже избегает неудобных вопросов и разговоров.
Шаг 3. Помощник менеджера по снабжению
Я начал заниматься деятельностью, которая, как мне казалось, была соткана из моего предыдущего опыта в этой организации.
Тут тебе и разноуровневое общение, и понимание номенклатуры, и стремление к порядку, к соблюдению сроков и прозрачности!
Тезис №4
Всегда-всегда старайтесь избегать “секретиков”. То, что у Вас происходит, должно быть на виду всегда. Бóльшее количество косяков из-за непрозрачности. Во всяком случае, именно недоговорённости были причинами дурацких проблем (например, когда 2 или больше человека делали примерно одно и то же, тем самым задваивая работу и получая в финале 1 результат).
Собирайте совещания с коллегами, другими линейными руководителями, подчинёнными (про них напишу чуть позже), с другими отделами. Все должны быть в курсе всего.
Так вот.
Как уже говорил, я начал заниматься вещами, которые мне были близки: налаживал, чинил и придумывал. Начались задачи куда более серьёзные, чем просто пообщаться, начались деньги, дебиторские задолженности, договоры поставок, сроки, доп.соглашения и гарантийные письма, и много чего ещё.
Я был воодушевлён, признаюсь. Меня радовало, что я чего-то там решаю, на что-то влияю. И по причине того, что мне, как мы уже выяснили, периодически становится тесно, я довольно быстро дорос до полноценного менеджера по снабжению.
Мой дебютный проект, который я начал и не очень, кстати, успешно закончил, подарил мне 100 очков опыта вообще по всем процессам, думаю, которые вообще только возможны в коммерческой организации (вот от вопросов АХО до юридических вопросов и бухгалтерии). И со временем я стал ведущим менеджером по снабжению.
Сколько допущено ошибок я даже не возьмусь считать, но я всегда находил в себе хоть чуть-чуть сил на честность и говорил, что у меня не получилось.
Тезис №5
Попытайтесь научиться любить время и дарить его всем как можно больше. Себе в первую очередь. Это не эгоизм! Эгоизм- это когда кто-то хочет, чтобы Вы делали так, как ему надо. А делать что-то так, как надо Вам- здравый смысл.
Простите за долгое начало, осталось совсем чуть-чуть!
За время моего развития и компания развивалась, конечно. Росло число сотрудников, масштабы объектов, уровни сложности и, конечно, бюджеты.
Когда я устроился компания состояла из 13 человек, а на сегодняшний день их 500+. Считай, развивались вместе 🙂
Конечно, в определённый момент мне и в должности ведущего менеджера по снабжению стало тесно и мы пообщавшись с руководством пришли к выводу, что я делаю с нуля административно-хозяйственный отдел. Что ж, у бизнеса есть потребность, у меня есть энергия, силы и идеи.
Ну и, собственно, отдел был создан. Были наняты сотрудники, придуманы процессы, сделаны бюджет и регламенты. Всё шло ровно и хорошо. До момента звонка Славы (если забыли- это тот звонок из начала статьи).
ИТ
На своё первое ревью я ехал так. Вызвал такси с объекта, доехал до аптеки. Купил Глицин в шипучке, бутылку воды. 2 таблетки Глицина закинул в бутылку, выпил, вызвал такси и поехал на свой первый в жизни дейли.
Что могу сказать. Весь мой опыт и знания, которые я копил очень долго (у меня трудовому стажу в этом году 16 лет) как-будто вышел из чата.
Вот совсем.
Я сидел и смотрел на молодых людей, которые что-то говорят, над чем-то смеются и я, который вообще нифига не понимал просто сидел, молчал и улыбался. Честно сказать, я и сейчас, спустя почти год, не всегда понимаю, о чём идёт речь.
Слава меня мимоходом представил примерно: «А это у вас там Иван, он типа тимлид.» Что ж, спасибо, Слава:)
Я думаю, что период адаптации достоин отдельного повествования, поэтому его пропущу.
С какими проблемами и сложностями столкнулся, когда чуть‑чуть освоился. А на самом деле с весьма простыми:
Сложная коммуникация или отсутствие коммуникации в срезе Бизнес-Продакт-Разработка;
Плохо описанные или не описанные вовсе задачи для разработки;
Непрозрачные процессы формирования задач (что/как должно работать/зачем вообще надо/как будет сочетаться с тем, что уже есть и т.д.);
Нерегулярные встречи внутри разработки;
Неопределённость;
Отсутствие сроков выполнения задачи;
Неполная команда;
И ещё всякого а-ля командное настроение, организационные вопросы и прочее.
Поскольку я не только управлял командами, но и формировал команды (правда в других отделах и сферах, если угодно), я отчётливо понимал, что мне нужен прикладной опыт того, как работает разработка и тут я совершил первую ошибку.
Ошибка
Я начал изучать информацию, которую находил в интернете. Всю. Любую. Много. Выбирайте тщательно, что читать и на что обращать внимание. Отчасти могут помочь книги «Как пасти котов» авторства Дж. Ханк Рейнвотер и «Мама, я тимлид» Марины Перескоковой. Там можно найти ответы на некоторые вопросы, которые возникают в самом начале пути, если у Вас нет опыта руководства и некоторые рекомендации.
Например:
Как привыкнуть к роли руководителя
Как руководить собой
Как организовать успех
Почему не надо замалчивать успех
Как и зачем надо делиться задачами
Как продумывать нагрузку
Потом я отказался от столь шквального получения информации и решил для себя, что лучший для меня вариант- это планомерное погружение, чтобы избежать кессонной болезни.
Я честно на одном из дейликов сказал команде, что не понимаю в том, что они делают, но готов вникать, параллельно помогая с процессами внутри команды. То есть у нас получился неплохой симбиоз- я чиню процессы, команды чинит мои хардовые скиллы. Опять же, очень важна честность и прозрачность. Я такое прям проповедую.
Итак, наши проблемы. 1.Сложная коммуникация или отсутствие коммуникации в срезе Бизнес-Продакт-Разработка.
Поскольку я давно работаю в организации, то у меня не было каких-то особых проблем с тем, чтобы объяснить команде, почему Генеральный директор выдаёт именно такие распоряжения или почему мы начинаем делать те или иные вещи, вот, именно сейчас. Важно отметить, что мои ребята находились в небольшом вакууме. Его, собственно, и разгерметизировал. Я долго и терпеливо отвечал на вопросы. Признаться честно, делал это с удовольствием.
Пообщался с продактом и попросил его подготовить красивую презентацию, на которой он отобразил все лиды, деньги с продаж, показал roadmap, ответил на вопросы. Как следствие, у разработчиков, которые были заключены на 3 этаже появилась информационная форточка, откуда дует пониманием.
Итог- команда не просто работала в каком-то там юридическом лице, а в понятной крутой организации, которая понятно чем занимается, что делает, какие занимает позиции на рынке и зачем они, то есть разработчики, трудятся. 2.Плохо описанные или не описанные вовсе задачи для разработки
Не буду долго описывать, как решился этот вопрос. На самом деле мы просто взяли в команду крутого бизнес аналитика со столь нужным нам опытом системного аналитика. И у нас починилась поломка формирования описательной составляющей задач. Мы и до сих пор стремимся к тому, чтобы получая тасочку в работу, программист говорил: "Угу, понятно" и просто приступал к реализации.
Безусловно, предела совершенству нет и мы постоянно стараемся сделать как можно лучше описание, помятуя о том, что лучшее- враг хорошего.
Итог - задачи обрели своего переводчика с менеджерского языка на язык технический. Стали понятными исполнителям.
3. Непрозрачные процессы формирования задач (что/как должно работать/зачем вообще надо/как будет сочетаться с тем, что уже есть и т.д.).
Если честно, мы до сих пор работаем над этой вещью.
Это сложно. Сложно потому, что в наших реалиях Продакт - это своего рода Генеральный директор продукта, который отвечает за деньги, за репутацию нашего продукта. Он проводит очень много время на встречах, например, с отделом продаж и времени на то, чтобы объяснить, зачем мы именно сейчас делаем ту или иную вещь катастрофически не хватает, но... дьявол, как известно, в мелочах!
И даже тут придумался способ, который известен как Product refinement document. Если вынести основное, то при формировании задач наш любимый Продакт как бы отвечает на вот такие вопросы:
Список требований к конкретному продукту
Если немного расшифровать, то документ с требованиями к продукту (PRD) - это документ, содержащий в себе все требования к конкретному продукту.
Он описан так, чтобы участники команды (разработка, дизайн) могли понять, что должен делать продукт или функциональность. Как правило, PRD НЕ ДОЛЖЕН предвидеть или диктовать, как продукт будет это делать.
С помощью таблицы выше предлагается описывать глобальные функциональности или функциональности затрагивающие большое количество элементов системы, редизайн различных флоу, страниц или вкладок. Различные мелкие исправления с помощью этого документа описывать не надо.
Итог- появилась прозрачность не только каких-то отдельных элементов для каких-то отдельных частей команды, но и в целом все всё начали понимать и видеть. И глобальный извечный вопрос: "НАХРЕНА ЭТО ВООБЩЕ НАДО" стал звучать всё реже :)
К тому же качество кода растёт, поскольку разработчик стал видеть чуть шире
4.Нерегулярные встречи внутри разработки
Мы работаем по двухнедельным спринтам и у нас было планирование. По нашей традиции проводилось оно по четвергам, каждые 2 недели (то есть аккурат в момент окончания старого спринта и начала нового).
Обычно планирование длилось 2-3-4 часа и выматывало людей, которым задачи планировались и которые эти задачи планировали.
У UX/UI в январе висели сделанные ими в ноябре задачи, а QA почему-то были вообще в стороне. Непорядок!
Что сделалось:
а) По средам, перед планированием, начали проводить предпланинги (с нэймингом у меня плохо, факт). Предпланинг- это встреча по стекам (то есть дизайн отдельно, бэкенд отдельно, фронтенд отдельно), которая проводится до планирования с целью ознакомления разработчиков с задачами. Также на этих встречах Продакт отвечает на вопросы, если таковые возникают, дизайнеры показывают, чего они там нарисовали (дизайнеры просят говорить не нарисовали, а напроектировали). На всех встречах присутствуют тестировщики, которые могут сразу рассказать, что может сломаться, что на что может заафектить, на что надо обратить внимание.
И вся эта компашка уже снижает уровень непрозрачности вообще до минимума. Приятный бонус- вся команда в курсе, что делает вся команда и время планирования сократилось. Сильно. Самый короткий планинг занял у нас 13 минут. Потому что все всё знают, все оценили свои задачи (стоит сказать, что мы используем оценку сложности задачи- это sprint point. В спринт у разаработчика не может быть более 16 SP и не может быть двух задач по 8 SP).
b) Дизайн-ревью. Каждый понедельник, в 14:00 мы (тимлид- это я, Продакт, бизнес аналитик, дизайнеры, тестировщик и... ведущие специалисты каждого стека) собираемся и смотрим, что же там нарисовали напроектировали дизайнеры. Что-то отправляется на переделку, что-то проваливается в работу.
Зачем тут разработчики и тестировщик? А это потому, что у наших крутых дизайнеров богатейшая фантазия :)
Итог- не могу сказать, что стерильно, но стало в разы лучше с понимаем того, что мы все тут делаем и за что нам платят. Никаких секретиков между стеками.
5,6 Неопределённость, Отсутствие сроков выполнения задачи
Соединю эти пункты. Вообще, неопределённость определённо (опа, каламбурчик) сходит на нет. К сожалению, это небыстрый процесс. Я не сильно топлю за то, что мы должны к какому-нибудь понедельнику или началу нового месяца иметь 100% определённость в том, что у нас происходит. Всё-таки к нам спускаются задачи от бизнеса иногда и меняются приоритеты в дорожной карте, что не способствуют продуктивности. Но у нас такие данные. С ними и работаем.
Про отсутствие сроков выполнения задач, на самом деле, ответил выше. У нас появились SP, у нас есть адекватный и причёсанный roadmap. Разработка с хладнокровностью Лаврентия Берии разбирает свои задачи. Превращением эпиков в атомарные таски занимается бизнес аналитик.
Итог. Продакт шарит и доверяет разработке, разработка ещё как шарит и доверяет продакту.
7. Неполная команда
К решению этой проблемы подошёл со всей ответственностью и из 9 мы превратились в 17 человек.
Команда стала большая:
- 1 тимлид (это я, кстати) раньше не было - 3 мобильных разраба (их и было 3) - 4 тестировщика (было 2) - 2 дизайнера (был 1) - 2 бэкенда (был 1) - 4 фротнендера (было 2)
Сейчас всё хорошо :)
8. И ещё всякого а-ля командное настроение, организационные вопросы и прочее
Как и говорил, я довольно давно работаю в организации и совершенно просто и несложно решаю вопросы своих ребят в бухгалтерии, у юристов, по больничным и отпускам. То есть я стремился сделать так, чтобы разработчики разрабатывали, а не ходили куда‑то, чтобы получить справку с места работы:)
Командное настроение чинилось своим примером. Я подходил и подхожу к каждому периодически с вопросами: «Всё ли получается? Не нужна ли помощь?»
Каждый день я здороваюсь и прощаюсь со всеми за руки. Прям обхожу каждого. Я хвалю своих ребят на каких‑то общих встречах публично. А, вот, ругать (ну, как ругать, по факту срыва срока, допустим) всегда предпочтаю 1 to 1.
Собственно, к чему весь этот текст.
Мой вывод, в общем, в том, что если ты кем-то руководишь, то тебе, как-будто, не очень нужны какие-то инструменты. То есть они, конечно, нужны, но всё строится на общении, на адекватности, на доброте и дружелюбности. Также важно понять, когда тебе сели на шею! Также я убеждён, что сначала ты взаимодействуешь с человеком. С его хотелками, с его состоянием и настроением, а уж потом только с коллегой или подчинённым. Кстати, про настроение. Я также за много лет управления убедился, что надо управлять эмоциями. Важная штука, попробуйте!
Все думаю, что программирование требует специального мышления. В какой-то мере это верно, но программисты развивают свой стиль мышления, занимаясь не только программированием.
Сегодня как раз об этом.
Программирование — это решение проблем. Программисты постоянно развивают навыки абстрактного мышления, декомпозиции и творчества через решение задач.
Поэтому попробуйте и вы рассматривать проблему как хобби или творчество. Это может сделать процесс более интересным и приятным.
Разбивайте задачи на подзадачи. Этот метод упрощает разработку, тестирование, да и вообще любые дела. Поэтому применяйте подход «разделяй и властвуй» в повседневной жизни. Это поможет решать задачи более эффективно.
Исследуйте проблему с разных сторон. Это поможет вам найти более надежные решения.
Также и в повседневной жизни. Когда у вас возникает очередное срочное дело, не торопитесь сразу его решать. Попробуйте придумать несколько способов решения, проанализировать их и сравнить.
Именно так поступают программисты. Они начинают с создания плана будущего кода, прежде чем приступить к работе.
Погружайтесь в детали, чтобы понять, как работает «под капотом». Это поможет создавать более эффективные решения.
Обычно мы пытаемся решить проблему, сосредоточившись именно на ней, а не задумываясь о том, как она работает изнутри. Это удобно, потому что так мы делаем все быстрее. Но такой подход иногда ограничивает наше понимание. Если мы углубимся в детали, можем избежать лишней работы и использовать способы решения проще.
Если вам было интересно это прочитать (да и в целом интересна сфера айти и всё, что с ней связано), подписывайтесь на наш телеграм-канал. У нас только самые яркие новости из мира айти, куча полезной инфы (бесплатно и без регистрации :D), обзоры на ИИ-стартапы и мемы, конечно, куда ж без них :)
Мы постарались сделать каждый город, с которого начинается еженедельный заед в нашей новой игре, по-настоящему уникальным. Оценить можно на странице совместной игры Torero и Пикабу.
Хочу поговорить с вами об эффективности и своем наблюдении, в первую очередь за собой.
Я описывал в своем посте о своем устройстве в IT, и там было сказано, что я работал в поддержке Яндекса, а потом в техподдержке Яндекса. Хочу обратиться к этим временам и построить на этом свою мысль.
В поддержке и техподдержке Яндекс сделал очень мудро. Он установил показатели, по достижению которых выплачивается премия, и самое главное он столкнул всех сотрудников лбами. То есть буквально был рейтинг, и чем ты выше, тем больше ты получишь премию. Люди работали, я сам садился и фигачил все 12 часов, чтобы я был выше в рейтинге (он конечно зависит еще от оценок, но общее количество тоже имеет значение). Дальше они просто показывают тебе, сколько ты заработал в реальном времени. И все это успех, появляется конкурентная среда, все сотрудники работают на премию и на рейтинг! В техподдержке было по-другому, но подобная система.
Казалось бы, причем тут IT? Да при том, ребята, айтишники зажрались, и я сейчас не про деньги, а про аджайлы и прочую дребедень. Айтишник (именно технический специалист) сейчас не слишком хочет работать, а менеджеры им в этом помогают! Нет конкурсной среды, все молодцы, все хорошо работают! Со всеми HR проведет квартальную встречу и расскажет, какие они продуктивные красавчики! И не важно, что ты работаешь 3 часа в день из 8. И самое главное, программисты, девопсы, QA и остальные привыкли к этому.
Основная мысль такова: нужна конкуренция, легкоатлеты на соревнованиях не бегут все одинаково хорошо, кто-то хуже, а кто-то лучше, и им так и говорят: "Ты пробежал хуже, ты второй, вон тот парень лучше тебя". Это мотивирует, и благодаря этому они бегают быстро, а не легкой пробежкой. Так и только так, мы будем развиваться.
Я прохожу ораторский курс, и он часто заставляет меня окунуться в свои чертоги разума.
Пять лет назад В 2018 году я уже год как менеджер проектов, были первые релизы, реально крутые и сложные клиенты. Кайф. Где-то могу вырулить на опыте (как я ошибался). И в какой-то момент случились «кровь, ошметки», откуда я не смог выбраться. Или уже не хотел выбираться.
Если коротко: промотал синхронизацию двух команд — нашей и клиентской, в итоге наша команда ~10 человек на месяц осталась без загруза. И в этот момент по другим проектам пошли какие-то несостыковки. Посыпался. Выгорел. Уволился.
Для себя подумал — нахер этот диджитал, буду искать себя в другой сфере.
Как вы понимаете — позже передумал ☺️
Взвесил все за и против, наткнулся на один из вариантов данного графика. Понял — расти больно, но без роста я так и буду ходить в падаванах.
Сейчас Пережив эту ситуацию, я вернулся в управление проектами. Четыре года верой и правдой рулил командой, помогал заказчикам оцифровывать их бизнес, пока не пошел на повышение.
Теперь я помогаю менеджерам расти, справляться психологически и физически.
Обязательно обсуждаем с менеджерами, которые устраиваются в нашу компанию, этот график. Гладкого роста не бывает, это больно, это сложно. Но результат себя оправдывает!
Войти в IT можно и без программирования: например, стать менеджером. Собрали полезные уроки из вводных частей наших курсов — все они бесплатные. Проходите, пробуйте свои силы в профессии и решайте, насколько она вам подходит.
Эффективная постановка задач
Сколько времени займет: ~3 часа
Качество управления командой напрямую зависит от того, как менеджер формулирует задачи. Чтобы вы делали это грамотно, в уроке научим методу SMART. С ним ваши таски будут максимально понятными, емкими и лаконичными — сможете уверенно делегировать обязанности, чтобы получить нужный результат.
Хорошему менеджеру нужно уметь анализировать информацию, делать верные выводы и принимать на их основе вдумчивые решения — во всем этом поможет критический склад ума. Это важный навык не только в IT, но и в жизни — мы даже посвятили ему отдельный пост. В бесплатном уроке вы научитесь азам критического мышления и сможете аргументированно защищать свои решения и обосновывать предложения.
Важная часть работы менеджера проектов — вести постоянный диалог с командой. В этом уроке вам предстоит сопроводить разработку функции бронирования учебного сервиса Яндекс Капсулы. Вы пройдете весь путь проджекта от дизайна до тестирования: научитесь ставить задачи разработчикам и дизайнерам, а еще решать конфликты внутри коллектива.
Рано или поздно руководителю приходится подбирать новых сотрудников в команду. Пройдите урок — и научитесь искать подходящих кандидатов, потренируетесь проводить собеседования и изучите весь процесс найма тестировщика для приложения Кибердом.
Большой комплексный урок, который поможет разобраться в том, что такое цифровой продукт, и изучить его жизненный цикл. В процессе предложим пройти небольшой полезный тест — он покажет, что вам уже известно из этой области. А еще расскажем, чем занимается продакт-менеджер, чтобы вы получили общее представление о профессии и поняли, подходит ли она вам.
Пройти бесплатные вводные части можно и по другим IT-направлениям Практикума. Попробуйте себя в программировании, дизайне, аналитике и маркетинге: в комфортном темпе изучите теорию и выполните задания в онлайн-тренажере — узнаете много полезного. А еще будет проще определиться, что нравится, и перейти к полноценному обучению.
IT-шники – люди особые. Но если вы представляете себе небритых и пахнущих потом и фастфудом пещерных людей, которые уже лет 10 не видели света, то ошибаетесь. Есть, конечно, свои отклонения. Например, у себя в компании вместо традиционного корпоратива с вином и стейками мы устроили битву программистов. Позвали коллег из Android и iOS, чтобы решить, наконец, многовековой спор кто лучше.
Что мы сделали:
1. Подобрали задачи. Это было сложно. Хотя все мы занимаемся одним и тем же у наших сред разное назначение. 1С – программы для бизнеса со сложными расчётами, таблицами и графиками. Специалист должен знать не только язык, но и разбираться в области, для которой пишет. Работают в 1С чаще всего на компьютере. Android- и iOS-приложения создаются для мобильных устройств и решают разные задачи – от ведения учёта до развлечения. Но программистам нет необходимости погружаться, например, в бухгалтерию или кадровый учёт. Сошлись на общих задачах – на логику, вероятность и пр.
2. Прорешали задания сами (на 1С – руководитель нашей компании, на Android и iOS – руководители компании-партнёра). Выставили ограничения по времени и продумали систему оценивания. Добавили задание для команд.
3. Определились с местом и датой проведения состязания. С первым всё оказалось просто – нам нужны компьютеры, рабочие столы и удобные кресла. Это всё есть в офисе. С датой было сложнее. Останавливать работу даже ради крутого мероприятия мы не хотели, поэтому единогласно сошлись на выходных.
4. Придумали крутое название – Цифровое состязание CodeFest. Подготовили презентацию.
5. Организовали корпоратив после соревнования. Пиццы в перерыве нам показалось мало, и мы заказали вкусную еду прямо в офис, достали со шкафа настолки. Играли, разговаривали, обсуждали задачки – отлично провели время.
Самое интересное – результаты
Победила, как говорится, дружба. Первое место занял разработчик iOS, второе – 1С, третье – Android. Так, мы поняли, что не бывает нерешаемых задач, «неправильных» сред программирования и конфликтов между разработчиками. Формат мероприятия понравился всем – и участникам, и болельщикам, и руководству. Обязательно повторим в следующем году.
Выкручивайте остроумие на максимум и придумайте надпись для стикера из шаблонов ниже. Лучшие идеи войдут в стикерпак, а их авторы получат полугодовую подписку на сервис «Пакет».
Кто сделал и отправил мемас на конкурс — молодец! Результаты конкурса мы объявим уже 3 мая, поделимся лучшими шутками по мнению жюри и ссылкой на стикерпак в телеграме. Полные правила конкурса.
А пока предлагаем посмотреть видео, из которых мы сделали шаблоны для мемов. В главной роли Валентин Выгодный и «Пакет» от Х5 — сервис для выгодных покупок в «Пятёрочке» и «Перекрёстке».
Реклама ООО «Корпоративный центр ИКС 5», ИНН: 7728632689