Путь в ИТ. Елена Правдина

требуют адекватной оценки, планирования и обеспечения выполнения в оговоренный срок самим разработчиком. И если раньше менеджеры несли вину за срывы сроков, сейчас всё больше культура компаний ведет к тому, что ответственность за оценку времени и их соблюдение перекладывается на программиста. Если же вы, выбирая ИТ, грезите фрилансом, удаленной работой – самоорганизация понадобится вам вдвойне. Начните с малого – плана на день, и научитесь полностью выполнять его. Честно отвечайте себе, почему не смогли. Были недостаточно быстры? Оттачивайте мастерство, используйте вспомогательные инструменты. Запланировали слишком много? Отделите желаемое от действительного, учтите предыдущий опыт выполнения подобных дел для понимания требуемого времени. Нашлись более срочные дела? Оцените важность всех задач и выберите меньше, но из самых нужных.

      Привыкайте брать ответственность и проявлять инициативу. Тренируйтесь на других сферах – подумайте, как оптимальнее пройти от дома до работы или университета, как передернуть привычный шаблон поведения в стандартной ситуации, как сократить время сбора утром. Попробуйте мыслить нестандартно, взяться организовать расстановку книг в домашней библиотеке или проведение небольшого митапа в известной вам области. Зачем? Затем, что, смотря наперед, – это те важные софт-скилс, к желанию видеть которые в своих сотрудниках сейчас приходит индустрия ПО. Методологии построения рабочего процесса, равно как и критерии оценки сотрудников (быть может, сами того не осознавая) исходят из наличия у топовых сотрудников способности предлагать улучшения, внедрять их в команде и… отвечать головой, если твой «улучшающий код» внезапно отправил сервера прилечь на пару часов на незаслуженный отдых. Подход управления разработкой Scrum поощряет участников команды, склонных брать на себя дополнительные роли (например, роль scrum-мастера). Подход с наличием начальника-надзирателя, увы, устарел. Сейчас до разработчика спускается задача, детали реализации которой, ожидается, предложит он сам. Более того, всё больше распространяется презентация результата заказчику напрямую самим разработчиком. А это значит, что вы должны уметь собрать информацию о проделанной работе со всей команды и красиво ее подать, общаться и выступать перед людьми, держаться уверенно, ориентироваться в моменте и быть немного политиком, отвечая на неудобные вопросы заказчика. Выступления на конференциях, написание статей, предложения по организации процессов учитываются наравне с ответственным и качественным программированием нужной фичи – прямыми обязанностями разработчика. Проникнитесь, насколько нужные здесь качества далеки от стандартных базовых черт хорошего разработчика. По моему опыту, компании склонны нанимать «человека, умеющего говорить», чем подчас более глубокомысленного и вдумчивого специалиста с яркими чертами интроверта. Как по мне – уход не на ту