Алексей Киселев

Мы пользуемся acunote. Для команд до 5 человек бесплатна.
Если нужно взаимодействовать с клиентом, может лучше подойдет asana.

Люди становятся руководителями в том момент когда осознают, что большие возможности приходят только с большой ответственностью.

Хорошо подумайте, готовы ли взять на себя ответственность за выполнение работы перед начальством, владельцем компании и ее клиентами с одной стороны и перед своими подчиненными с другой.

Технически стать руководителем не так сложно. Главное взять ответственность. Проявите инициативу. Начните с малого, берите на себя больше будучи ведущим разработчиком. Руководство вас обязательно заметит, инициативных людей проценты, а готовых отвечать за свои слова еще меньше. У руководства постоянный голод на таких людей. Руководство мечтает об открытии новых направлений, но им некому их отдать. Им нужно найти человека которому можно показать направление куда идти. И он сам организует все что нужно чтобы туда прийти: найдет людей, помещения раздаст задания дизайнерам и продажникам, закажет сайт и т.д. и т.п.

Если вы не готовы брать дополнительные обязанности без соответствующего вознаграждения. Или у вас в голове вертятся фразы типа "Не по зарплате вопрос", даже и не мечтайте о руководящей должности. Жизнь устроена так, что сначала инвестиции, а потом вознаграждение.

Для @Masterme. Любой тяжелый и продолжительный труд со стороны выглядит как удача.

Я думаю можно. Главное в управлении проектами знание техник управления, методологий. Умение программировать позволит быстрее наладить связь с командой, они будут считать тебя "своим". Без этого умения ты - "чужой". Просто дополнительная сложность с которой можно справиться.

1. Попроси знакомого программиста с опытом помочь тебе на собеседовании. А сам задавай больше вопросов по мотивации, выясняй амбиции разработчика. От этого будет зависеть его вовлеченность в процесс.

2. Оценивать производительность нужно по методике. Возьми хотя бы Agile. Там после нескольких итераций становится ясно у кого какая скорость. И с какой скоростью может двигаться команда. Причем, если строго следовать методологии, то становятся даже заметны обманы с оценками со стороны разработчиков.

3. Оценивать трудоемкость выполнения задач должны разработчики, так как им их делать. Твоя задача следить за тем правильно ли они сделали оценку и корректировать ее. Как правило разработчикам свойственен излишний оптимизм. И ты чаще будешь им говорить: "В прошлой итерации ты оценил задачу #1234 в 12 идеальных часов, а потратил 3 дня (18 часов). Не ошибаешься ли ты в этот раз?"

И еще несколько советов от себя:
1. Выбери методологию разработки, изучи ее и строго следуй ей. Это очень помогает.
2. Почитай про различия менеджерского цикла и цикла разработчика. Уважай способ работы разработчиков и не отвлекай их по пустякам. Методологии и об этом заботятся, в них всегда есть ритм, разработчики к нему привыкают и перестают замечать затраты на следование методологии.
3. Закрывай собой разработчиков от вышестоящего начальства, не давай ему вмешиваться в рабочий процесс в обход методологии. Это отличный способ заслужить уважение команды.

Удачи!