фото с сайта pilot.com
В 2012 году Джессика МакКеллар с командой друзей из MIT (Массачусетский Технологический Институт) запустила стартап скрытого чата Zulip. Менее двух лет спустя его выкупил Dropbox. И в этом не было ничего необычного. С ее командой такое уже случалось, когда они так же быстро продали Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше опыта в разнообразных возможностях менеджера, чем обычный инженер получает за всю карьеру. Она была тимлидом, основателем, техлидом в огромной корпорации, а сейчас руководит десятками сотрудников в быстрорастущем международном стартапе. (Да, она еще и значимая фигура в мире Python). В статье Джессика рассказывает о своем опыте и подходе к управлению командами.
Поддерживать высокое техническое качество кода — прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.
Приведенные в статье примеры и истории помогут читателям выстроить баланс между продуктовыми и техническими задачами в диалоге с заказчиком и руководителями. А проверенные на практике советы — правильно подготовиться к этому разговору.
Последние пять лет я работаю в аутсорсинге, поэтому часто занимаюсь запуском новых продуктов. Чаще всего первый шаг - создание так называемого MVP (minimum viable product).
При запуске MVP большинство компаний стремятся зафиксировать сроки и бюджет: еще нет уверенности, что бизнес-модель продукта жизнеспособна, поэтому требуется как можно быстрее проверять гипотезы на практике. Когда (и если) продукт выстрелил, приходят настоящие пользователи, которые хотят не только новые фичи (и как можно быстрее), но и стабильность продукта. Их перестает устраивать продукт, собранный на коленке. Поэтому сроки остаются актуальными, но вместо бюджета на первый план выходит качество.
Проблема в том, что мы каждый раз оказываемся в том самом знаменитом треугольнике компромиссов, но два угла, которые мы должны выбрать — не совпадают. Довольно часто эту дилемму предлагают решать в формате «давайте сначала сделаем прототип, попробуем его, а потом выкинем и с нуля перепишем все уже по-хорошему». К сожалению, на практике осуществить этот трюк удается довольно редко. Поэтому многим командам приходится годами жить с «архитектурными» решениями, заложенными на этапе тестирования гипотез.
Сегодня я расскажу, как мы вышли из этого треугольника (мое выступление на эту тему).
Общаться в профессиональной среде, ходить на конференции и митапы, просто посидеть вечерком в приятном баре с профессионалом высокого уровня и обсудить какие-то классные идеи: всё это может помочь в работе. Среди нужных ресурсов одно из первых мест занимают книги.
Под катом я расскажу вам о литературе, которая оказала на меня влияние как на управленца и разработчика. И, как мне кажется, может быть полезна любому, кто хочет вырасти в этих областях.
Все наши приложения так или иначе могут быть подвержены уязвимостям. Это, в свою очередь, может привести к финансовым потерям и спровоцировать утечку данных клиентов.
Зачем и от чего защищаться? Какие инструменты для этого существуют, в том числе Open Source? Что такое Secure Software Development Lifecycle? Александр Киверин — технический директор в Ак Барс Цифровые Технологии — рассказал об опыте своей компании на TechLead Conf 2020 Online. А мы подготовили расшифровку.
Всем привет! Сегодня в гостях у нас Олег Мельник — Technical Lead в компании Proxify, а также преподаватель в OTUS.
Поговорили с Олегом про такую роль у разработчиков как техлид.
Статья коллеги про отношение к вынужденной удалёнке вдохновила меня рассказать о самом серьёзном испытании, с которым я столкнулся в первые полгода такого режима: грумминг сложных задач стал невыносим. Под катом я постарался не только рассказать о проблеме, но и поделиться своими соображениями о её решении. Возможно, кто-то сочтёт мои рассуждения очевидными и подумает, что были допущены детские ошибки. Но я также верю, что найдутся и те, кому мой опыт окажется полезен.
В 2006 году Яндекс и Google приехали в Петербург в Borland, который сокращал команду. Обе компании одновременно открывали в Петербурге свои офисы на его базе. Тогда к нам пришли замечательные ребята. Мы много общались, но больше всего запомнились слова Толи Орлова. Он сказал, что рост Яндекса на тот момент ограничивает только количество лидов, которые бы могли развивать продукты. Что роли техлида и тимлида очень существенны, и часто рост компании зависит только от наличия сильных лидеров. Тогда мне и захотелось узнать, как им стать.
Меня зовут Владимир Горовой. Я был тимлидом, потом перешёл в менеджмент, руководил созданием разных сервисов, в том числе, Яндекс.Путешествий. Сейчас работаю в Яндекс.Вертикалях. У меня есть разный опыт: менеджерский, разработческий и тимлидский. Всем этим и хочу с вами поделиться.
Привет! Меня зовут Саша, и с 2020 года я работаю в ЕВРАЗе — это металлургическая и горнодобывающая компания. Устроился сюда бэкенд-разработчиком, а сейчас — техлид.
Какие качества отличают хорошего технического лида? Уверены, как минимум инициативность, стратегическое видение, интерес к новым практикам и инструментам, идущие рука об руку с желанием постоянно развиваться. Немалую роль в lifelong learning техлида могут сыграть правильно подобранные книги.
Немет, Луц, Лав, Танненбаум, Страуструп, Олифер, Лукас — вот лишь некоторые известные авторы, о которых мы сегодня не будем говорить. Надеемся, что раз вы стали лидером технической команды, то с фундаментальной литературой в своей области знаний знакомы не понаслышке.
Под катом рекомендуем 7 изданий о soft-skills, методологиях, управлении командами и проектами.