Наше подразделение работает без руководителей с конца 2015 года. Сами решаем, кому и сколько платить, кто поработал хорошо, а кто не очень, кого нанять, а с кем расстаться. В статье расскажу про самое сложное — работу с людьми. Поделюсь тем как у нас инженеры аттестуют инженеров, кто теперь делает всю ту полезную работу, которую делали руководители и, конечно же, сколько человек пришлось уволить, чтобы это всё внедрить.
Читать полностью »
Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.
В статье будет приведено несколько терминов, а также примеры индустрий, где неграмотный менеджмент может привести к катастрофе.
Данная статья будет интересна всем тем, кто когда-либо собирается собрать собственную команду, открыть собственное дело, или уже это сделал, но что-то пошло не так. И еще, всем тем, у кого по непонятным причинам, проект не может завершиться уже длительное время.
Читать полностью »
Данный текст предполагает, что читатель ознакомлен с т.н.
agile-манифестом разработки программного обеспечения и его т.н. основополагающими принципами.
В настоящий момент существует огромное количество людей, которые принимают данный "манифест", соглашаются с ним, и даже пытаются применять. Но лично для меня это выглядит как шутка, которая затянулась.
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят
То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.
Многие сталкивались с новичком, который приходил в проект и заявлял, что «все необходимо срочно переделать». А некоторые и сами это говорили или думали. Это — «синдром сантехника»: поведение, характеризующееся желанием все сделать по-своему, «правильно», при работе над новым проектом или при переходе на новую работу. А значит, существующий код, технологии или инструменты нужно переписать, желательно «под себя». Тема была бы банальной, если бы не повторялась так часто от проекта к проекту, с каждым новым набором штата.Читать полностью »
Буквально несколько дней назад я наткнулся на вопрос в Hacker News — «Стоит ли нанимать и обучать джуниоров?[1]». В комментах развернулась бурная дискуссия, желающие могут сходить по ссылке и принять участие. Меня же эта дискуссия сподвигла поделиться с аудиторией хабра несколькими советами тем, кто хочет пройти первое собеседование на позицию программиста.
Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.
Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.
Agile вырос из среды веб-консалтинга, где он приносил определённую пользу: при работе с привередливыми клиентами, которые не знают, чего они хотят, обычно приходится выбирать из двух вариантов. Или одолеть клиента: установить ожидания, соответствующую оплату за переделки и поддерживать отношения равенства, а не подчинения. Или принять некорректное поведение клиента (как, скажем, приходится многим дизайнерам) и ориентировать рабочий поток вокруг клиентской дисфункции.
Читать полностью »
Когда кто-либо становится руководителем разработки, на него непременно обрушивается огромное количество новых, неожиданных задач, и для адаптации непременно требуется время. Однако период адаптации однажды завершится, и тогда встанет вопрос, как же развиваться дальше. Не менее актуальным является вопрос подготовки сотрудника к будущей роли руководителя. Как работать с разработчиком, чтобы из него как можно быстрее получился будущий лидер?
Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.
В этот раз нашими экспертами стали:
Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:
1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?
Привет! Меня зовут Иван Лукьянов, я хочу пригласить вас на devleads meetup — мероприятие для тимлидов, руководителей разработки и всех, кто интересуется особенностями управления командой в ИТ. Митап пройдёт 6 декабря в офисе Авито. Поговорим о том, как изменение подхода к менеджменту может оптимизировать стоимость мобильной разработки. Покажем чек-лист для сбора эффективной команды. С докладами выступят представители Skyeng и Авито. Пройдёт круглый стол с экспертами. Под катом — тезисы выступлений докладчиков, ссылка на регистрацию и информация о прямой трансляции встречи.
Мы знаем, как часто общение потенциальных кандидатов с HR воспринимается в штыки. Именно поэтому, когда вы сами в поиске новых классных сотрудников, вы не можете переложить все заботы на кого-то другого и надеяться, что вам принесут рок-звезду на блюдечке.
Для найма почти смертельно, если тимлид самоустраняется от процесса. Ваша личная история может так легко продать вакансию кандидату, как не сможет никакой HR-бренд. В условиях нехватки кадров, роль тимлида в рекрутинге одна из ведущих.
Доклад Катерины Гавриловой на Saint TeamLead Conf дает вполне конкретные, не слишком трудозатратные рекомендации для руководителей, которые хотят нанять к себе в команду своих людей и не потратить на поиски полгода.
