ведущий программист что делает
Что входит в обязанности ведущего разработчика
Вот эта большая статья Джона Олспау называется «Быть ведущим инженером». В первый раз я прочитала её примерно четыре года назад, когда только перешла на нынешнюю работу, и она действительно повлияла на представления об этом направлении моей карьеры.
Перечитав её сейчас, действительно интересной там кажется одна вещь, что эмпатия и помощь команде — важная часть работы сеньора. Что, конечно, является правдой!
Но сейчас я вижу, что большинство или все ведущие инженеры, которых я знаю, берут на себя значительную помощь другим сотрудникам вдобавок к своей личной работе по программированию. Сейчас мне кажется, что я и мои коллеги сталкиваются не столько с проблемой «Что?? Нужно РАЗГОВАРИВАТЬ С ЛЮДЬМИ?? НЕВЕРОЯТНО», сколько с другой проблемой: «Как сбалансировать всю эту руководящую работу со своим индивидуальным вкладом / программированием? Сколько и какой работы я должен делать?». Поэтому вместо того, чтобы говорить о признаках сеньора из статьи Олспау (с которыми я полностью согласна), хочу поговорить о работе, которую мы делаем.
О чём эта статья
«Чем занимается ведущий инженер» — огромная тема, а здесь лишь небольшая статья, так что следует иметь в виду:
Что входит в обязанности
Это вещи, которые я рассматриваю больше как работу ведущего инженера и меньше как работу менеджера (хотя менеджеры определённо делают кое-что из перечисленного, особенно создание новых проектов и связывание проектов с бизнес-приоритетами).
Почти вся эта работа по сути техническая: помочь кому-то справиться со сложным проектом — это явно человеческое взаимодействие, но проблемы, над которыми мы будем работать вместе, как правило, будут техническими! («Может, если упростить дизайн, то мы сможем быстрее справиться!»).
В списке отсутствует пункт «делать оценки/прогнозы». Здесь я ещё не очень хороша, но я думаю, что когда-нибудь стоит потратить на это больше времени.
Список кажется большим. Кажется, что если заниматься всеми этими вещами, то они поглотят все ваши интеллектуальные ресурсы. Думаю, что в целом имеет смысл выделить какую-то часть и решить: «Прямо сейчас я собираюсь сосредоточиться на X, Y и Z, я думаю, что мой мозг взорвётся, если я попытаюсь сделать B и C».
Что не входит в обязанности
Тут немного сложнее. Я не говорю, что такими вещами категорически нельзя заниматься. Большинство ведущих инженеров, которых я знаю, тратят огромное количество времени, думая об этих проблемах, и немного работают в этом направлении.
Но мне кажется, что полезно провести некоторую границу, потому что у некоторых людей высокое чувство ответственности за команду и компанию — и они готовы взяться за всё подряд, в результате чего будут перегружены работой и не смогут вносить технический вклад, который на самом деле является их основным делом. Поэтому установление некоторых границ помогает определить, по каким вопросам есть смысл попросить о помощи, когда ситуация становится неспокойной. Ваши реальные границы зависят от вас / вашей команды. 🙂
Большинство из перечисленного ниже — работа менеджера. Оговорка: менеджеры делают намного больше, чем перечисленное здесь (например, «создают новые проекты»), а в некоторых компаниях некоторое из перечисленного может фактически быть работой ведущего инженера (например, спринт-менеджмент).
Полезно явно задавать границы
Недавно я столкнулась с интересной ситуацией, когда обсуждала с менеджером свои обязанности — и мы поняли, что очень по-разному на них смотрим! Мы прояснили ситуацию, и теперь всё в порядке, но это заставило меня понять, что очень важно договориться об ожиданиях. 🙂
Когда я начинала как инженер, работа была довольно простой — я писала код, пыталась придумать проекты, которые имели смысл, и всё было прекрасно. У моего менеджера всегда было чёткое представление о моей работе, ничего слишком сложного. Теперь ситуация изменилась! Поэтому теперь я считаю, что обязана определить работу, которую:
Не соглашайтесь на работу, которую не можете / не хотите делать
Думаю, очень важно отказаться от работы, которую я не могу сделать или которая в долгосрочной перспективе не доставит радости! Кажется заманчивым взять на себя много работы, даже если она вам не очень нравится («О, это хорошо для команды!», «Ну кто-то же должен это сделать!»). Конечно, иногда я беру на себя задачи только потому, что они должны быть выполнены, но думаю, что для здоровья команды на самом деле очень важно, чтобы сотрудники делали то, что им в целом нравится и чем они могут заниматься в долгосрочной перспективе.
Поэтому я возьму небольшие задачи, которые просто нужно сделать, но важно не говорить при этом: «О, конечно, я потрачу большую часть своего времени на то, что у меня плохо получается и что мне не нравится, нет проблем» :). И если «кто-то» должен это сделать, возможно, это просто означает, что нам нужно нанять/обучить кого-то нового, чтобы заполнить пробел. 🙂
От младшего разработчика к старшему
Доброй день, Хабр. Вдохновленный статьей про системных администраторов, я решил написать нечто аналогичное для разработчиков.
Но прежде чем вступать на путь взращивания из себя старшего разработчика, нужно задать себе простой вопрос: «А мне нравится программировать?».
Старший разработчик. Взято отсюда.
Конфуцию принадлежит изречение: «Выбери себе занятие по душе, и тебе не придется работать ни одного дня!». И для разработчика это верно на сто процентов. Если приносит удовольствие написание кода, если переполняет радостью от того, что работает фича, если программа идет «just as planned» и это вызывает эмоциональный подъем — да, программирование будет приносить удовольствие и деньги, а главное — построение карьеры разработчика превратится в сущее удовольствие.
Так что же нужно делать?
1. Начинай рано
Основы алгоритмов начались у меня в начальной школе. В 7м начали преподавать паскаль, в 10м — C. Естественно, вряд ли здесь есть пятиклассники, но посыл таков: как только замечен первый интерес к программированию, его стоит подкреплять знаниями. Причем, школа все равно не даст хорошего понимания: если даже есть уроки программирования, то они не дают столь основательные знания, как книги. Итак, для старшей школы и просто для знакомства с темой предлагаю классическую «Керниган, Ричи: Язык программирования C». Признаться, эту книгу я заменил книгой с тем же названием, но за авторством Подбельского и Фомина.
2. Учись сам
Серьезно. Научиться программировать можно только программируя. Читай книги и мануалы. Разбирай примеры. Пиши собственные программы. Когда-то давно я хотел посмотреть одно аниме, но русского дубляжа не было, были субтитры в str(так ведь?). Беда в том, что инет был медленный и дорогой(привет, диалап!), а найденные субтитры отставали на пяток секунд. Понятное дело, что править файлы руками было очень долго, поэтому на C + WinApi было написано диалоговое приложение, которое принимало файл, размер и знак смещения, и формировало мне исправленный файлик сабов. Написано было естественно криво и бажно, но
а) Я решил задачу
б) Разобрался с основами WinApi
в) Научился дебагу и отладочному выводу
3. Поступи в универ по специальности
Даже если само программирование давать будут мало, в учебе есть несколько плюсов:
1. Математическая основа. Математика все равно пригодится. Будете ли вы писать простейший графический редактор под Android или игры под linux, будете ли реализовывать алгоритм шифрования — математика все равно нужна.
2. Будущие коллеги. Эти ребята — твои одногруппники и сокурсники — они тоже программисты в будущем! Ты можешь обменяться с ними опытом, а через 5 лет получить возможность устроиться в хорошую фирму по рекомендации. Да и всегда приятно обсудить профессиональные проблемы.
3. Связи университета. У пристойного университета всегда есть сотрудничество с IT-компаниями. Это могут быть разработчики железа, программного обеспечения или и того, и другого. Из этих компаний будут приходить специалисты и читать лекции — да, по субботам с утра. Но это возможность обучаться у людей, которые на волне в своей отрасли.
4. Начинай работу рано
Пытайся устроиться на стажировки. Много фирм-разработчиков особенно сейчас ориентируют свой кадровый поиск на студентов 2-3-4 курсов. Это связано в первую очередь с недостатком квалифицированных кадров, а потому компании решают выращивать такие кадры самостоятельно. После успешной стажировки обычно обещают рабочее место на 20-30 часов в неделю и не самые плохие деньги.
4. Разбирайся в основах
Пойми как работает компьютер. Что делает процессор, память, что такое такты, регистры, указатели, модели памяти. Понятно, что досконально знать архитектуру процессора необязательно. Но понимать, как исполняется программа, что такое стек и куча, знать надо уже на первом курсе.
Изучи структуры данных и алгоритмы. Они — основа всего. Решая любую прикладную задачу, сначала выбирают структуры данных и описывающие их объекты, и только потом их используют. Структуры данных в основе вообще всего.
5. Докапывайся и разбирайся
Это основной принцип развития. Не зная, как работает фундамент, невозможно понимать работу мало-мальски сложной системы. И, хоть все и говорят про абстракции, мы-то с вами знаем, что они текут. Поэтому в каждой проблеме нужно выяснять причину. Иначе получим культ карго. Не знаю, насколько люди осознают это, но только понимание принципа работы системы позволяет что-то делать в предсказуемые сроки. Это касается кстати не только программирования, но и вообще любой работы.
Изучай исходники того, с чем работаешь. Понятное дело, они доступны не всегда. Но если повезло иметь исходники, обращайся к ним. Если ты работаешь с Java — смотри как написаны классы библиотеки. Читать чужой код просто полезно, потому что читая — учишься, а заодно и понимаешь, что происходит когда вызывается та или иная функция.
6. Никогда не останавливайся
Каждый раз, когда получаешь какой-то кусочек знаний — например, принцип работы TreeSet — нужно почувствовать момент «Я крутой! Я знаю как это работает!». А в следующий момент усмирить гордыню и пойти дальше. Пусть получение знаний станет вдохновением для дальнейшего обучения.
7. Пользуйся лучшими инструментами
Писать в блокноте хорошо до тех пор, пока не наталкиваешься на инструмент с подсветкой синтаксиса. Такой инструмент хорош до тех пор, пока не знаешь, что такое автодополнение. Мысль понятна.
8. Общайся со старшими
Они опытней тебя и они поделятся опытом. Всегда спрашивай как лучше. Когда терзаешься между двух сомнительных вариантов, есть вероятность, что ты просто не видишь хороший. Сходи к своему техническому руководителю, он подскажет.
9. Помогай другим
Несмотря на то, что предыдущий принцип хорош, есть еще лучше: помогая другим, учишься сам. Зарегистрируйся на stackoverflow.com и отвечай. Мало того, что это хороший способ развития, профиль на SO — это строчка в резюме и путь к careers.stackexchange.com.
10. Ходи на собеседования
Внезапно, не для того, чтобы сменить работу. Зная, что спрашивают технические специалисты, можно понять, в каких областях знаний пробел. После можно прийти домой и этот пробел начать восполнять.
Понятно как стать программистом. А как стать старшим?
В моем понимании, старший программист — это человек, который может сделать весь проект сам, как минимум. Это значит, что он понимает принципы работы платформы. Он знает жизненные циклы приложения(не только, запустилось — поработало — выключилось, но и написано-протестировано, зарелизено, проапдейчено, удалено). Он может продумать архитектуру. Он может выстроить экосистему разработки. Старший программист — не просто разработчик. В его обязанности входит не только разработка, но и обеспечение процесса этой разработки. Это значит, что он хорошо знает свои инструменты. Он знает, как обеспечить качество продукта(тесты, инспекции), он знает, что собирать бинарник в один клик — важно.
Он может поставить задачи коллегам и подчиненным.
Как этого всего достичь?
Для меня ответ только один — собственные проекты. Открытые или нет, на заказ или на энтузиазме, неважно. Если вы устроились работать программистом, до «project setup» вас вряд ли допустят. А старшие — люди занятые, им не всегда удобно рассказывать, почему так или иначе выполнены тысячи мелочей. Понимание мелочей придет тогда, когда произойдет попытка с нуля поднять проект самостоятельно: настроить репозиторий с исходным кодом, создать структуру проекта, наладить инфраструктуру тестов, поднять continious integration, настроить на проект баг-трекер.
Что читать?
Я сам в основном java-программист. И потому книг по c++ или python советовать не буду. Вот список того, что я читал сам:
0. Язык программирования C (Подбельский, Фомин).
1. Java Certification for Java 6 2nd edition
2. Effective Java (Joshua Bloch)
3. Code Complete (Steve Macconnell).
4. Concurrency in Practise (Dug Lea & others).
Читать все лучше в оригинале. Понятно, что для этого нужен английский, но все лучшие материалы по программированию все равно на нем.
И какого качества код у меня будет получаться?
Единственный важный критерий у кода, кроме корректности его работы, является его читаемость. В большинстве случаев(молчим про производительность), ясный код — хороший код. Не буду припоминать про психоманьяка, который будет поддерживать код, но стремление к хорошо читаемому коду вытянет вас до высот.
Что должен знать и делать ведущий разработчик?
Уважаемые хабралюди, наверное многие из вас работают в офисе. Кто-то из вас работает под руководством человека, чью должность можно называть «ведущий разработчик», а кто-то таковым и является.
Пожалуйста, расскажите о вашем понятии, кто для вас человек в должности «ведущий разработчик», какие обязанности он выполняет, что он должен знать, какими качествами он должен обладать?
Может ли он знать в среднем меньше, чем члены его команды разработчиков?
Является ли это скорее административной должностью, где главное способность к управления, а не техническая подкованность?
У меня возникли такие вопросы, потому что всю свою профессиональную жизнь я был скромным самостоятельным фрилансером, теперь меня интересует образ жизни офисов.
Спасибо вам за ваши ответы.
Могу поделиться своим американским опытом, я тимлид, у нас в компании 5 команд. Каждый тимлид, в том числе и я должны:
Работать с менеджерами по проектам (которые формулируют задачи в целом)
Распределять работу внутри команды
Следить за своевременным исполнением работы
Проверять качество кода младших разработчиков
Нести ответственность за свою команду (спрашивать будут именно с тимлида)
Составлять тонны всяких отчетов
Тимлид отчитывается перед менеджером по разработке.
Кстати, у нас в компании тимлиды программируют не меньше остальных, а спрос с тимлида больше.
Тимлид не обязан знать больше чем члены его команды, однако он как правило спец в своей области.
Тимлид во многом администратор. Однако, он и программист. Тимлид принимает решения по поводу
тех или иных подходов к решению поставленных задач. Я бы сказал что тимлид это самая первая
ступень на менеджерском пути.
— Во-первых, он должен уметь аккуратно и вежливо говорить, обязательно, взвешивая каждое слово. Тоже самое в отношении его письменности. Это качество необходимо, как для общения с подчинёнными, так и с начальством и клиентами. Как не смешно, незнание русского языка плохо складывается на бизнесе.
— Во-вторых, он должен уметь организовать работу людей. Это качество личности изначально заложенное у порядка 10% людей, у остальных оно вырабатываться с опытом.
— В-третьих, он должен понимать систему, в которой он работает. Это касается и среды программирования, и области приложения. Например, ведущий программист АБС должен знать не только язык программирования для АБС, но и бухучёт кредитных организаций.
Эти три качества отличают хорошего ведущего программиста от плохого.
То есть я правильно понял? Этот человек должен быть:
— В чем-то дипломатом, чтобы уметь корректно обращаться с членами его команды и уметь улаживать трения.
— В чем-то менеджером, чтобы построить эффективную работу группы.
— И быть непосредственно техническим специалистом в области своей работы.
Спасибо, это хорошая систематизации.
Ведущий, если это не формальность, должен быть существенно лучше как девелопер — лучше и качественнее писать код, разбираться и править код своей команды — на него, как правило сваливают ответственность за управлением кодом в VCS в рамках работы своей команды, фичи или продукта. То есть знания и опыт работы с VCS необходимы.
Также ведущий часто выступает как эксперт в сфере своей компетенции. Пишет/создает дизайн, опеределяет свою часть архитектуры и так далее — смотреть в сторону архитекторов, евангелистов и фоллоувед
Дополнительно ведущий как правило
— определяет/подтверждает сроки и обьемы работ своей команды, участвует в планировании, управлении техническими рисками
— контролирует обьем и качество работы
— занимается рутиной в части управления обьемом работ, качеством, планами — эскалирует, подтверждает, рутит баги, пишет отчеты и так далее — смотреть в сторону работы ПМа, который делегирует часть ответственности на ведущего в рамках порученной его команде части проекта. То есть ведущий — это немного ПМ, совсем немного, но это другое направление нежели кодинг как таковой. По хорошему этому должны учить — курсы как минимум.
Сваливать на ведущего работу линейного менеджера для команды неправильно, но часто ему такое сваливается.
В развитых компаниях ведущий — это единственная позиция в которой совмещаются менеджерские и технические роли. Одни вырастают в дальнейшем в ПМ-ов, другие — в технических экспертов.
Должностная инструкция ведущего программиста
(ведущего инженера-программиста)
(профессиональный стандарт «Программист»)
1. Общие положения
1.1. Ведущий программист относится к категории специалистов.
1.2. На должность ведущего программиста принимается лицо:
1) имеющее высшее образование;
2) прошедшее повышение квалификации;
3) имеющее опыт практической работы в области разработки программного обеспечения не менее трех лет.
1.3. Ведущий программист должен знать:
1) возможности существующей программно-технической архитектуры;
2) возможности современных и перспективных средств разработки программных продуктов, технических средств;
3) методологии разработки программного обеспечения и технологии программирования;
4) методологии и технологии проектирования и использования баз данных;
5) языки формализации функциональных спецификаций;
6) методы и приемы формализации задач;
7) принципы построения архитектуры программного обеспечения и виды архитектуры программного обеспечения;
8) типовые решения, библиотеки программных модулей, шаблоны, классы объектов, используемые при разработке программного обеспечения;
9) методы и средства проектирования программного обеспечения;
10) методы и средства проектирования баз данных;
11) методы и средства проектирования программных интерфейсов;
12) Правила внутреннего трудового распорядка организации;
13) требования охраны труда, производственной санитарии и пожарной безопасности;
14) _____________________________________.
(другие требования к необходимым знаниям)
1.4. Ведущий программист должен уметь:
1) проводить анализ исполнения требований;
2) проводить оценку и обоснование рекомендуемых решений;
3) выбирать средства реализации требований к программному обеспечению;
4) вырабатывать варианты реализации программного обеспечения;
5) использовать существующие типовые решения и шаблоны проектирования программного обеспечения;
6) применять методы и средства проектирования программного обеспечения, структур данных, баз данных, программных интерфейсов;
7) осуществлять коммуникации с заинтересованными сторонами;
8) _______________________________.
(другие навыки и умения)
1.5. Ведущий программист в своей деятельности руководствуется:
1) _______________________________;
(наименование учредительного документа)
2) Положением о _______________________;
(наименование структурного подразделения)
3) настоящей должностной инструкцией;
4) ____________________________________.
(наименования локальных нормативных актов, регламентирующих трудовые функции по должности)
1.6. Ведущий программист подчиняется непосредственно _________________.
(наименование должности руководителя)
1.7. __________________________________.
(другие общие положения)
2. Трудовые функции
2.1. Разработка требований и проектирование программного обеспечения:
1) анализ требований к программному обеспечению;
2) разработка технических спецификаций на программные компоненты и их взаимодействие;
3) проектирование программного обеспечения.
2.2. __________________________________.
(другие функции)
3. Должностные обязанности
3.1. Ведущий программист исполняет следующие обязанности:
3.1.1. В рамках трудовой функции, указанной в пп. 1 п. 2.1 настоящей должностной инструкции:
1) осуществляет анализ возможностей реализации требований к программному обеспечению;
2) проводит оценку времени и трудоемкости реализации требований к программному обеспечению;
3) проводит согласование требований к программному обеспечению с заинтересованными сторонами;
4) осуществляет оценку и согласование сроков выполнения поставленных задач.
3.1.2. В рамках трудовой функции, указанной в пп. 2 п. 2.1 настоящей должностной инструкции:
1) осуществляет разработку и согласование технических спецификаций на программные компоненты и их взаимодействие с архитектором программного обеспечения;
2) распределяет задания между программистами в соответствии с техническими спецификациями;
3) осуществляет контроль выполнения заданий;
4) осуществляет обучение и наставничество;
5) формирует и предоставляет отчетность в соответствии с установленными регламентами;
6) проводит оценку и согласование сроков выполнения поставленных задач.
3.1.3. В рамках трудовой функции, указанной в пп. 3 п. 2.1 настоящей должностной инструкции:
1) осуществляет разработку, изменение и согласование архитектуры программного обеспечения с системным аналитиком и архитектором программного обеспечения;
2) выполняет проектирование:
— структур данных;
— баз данных;
— программных интерфейсов;
3) проводит оценку и согласование сроков выполнения поставленных задач.
3.1.4. В рамках выполнения своих трудовых функций исполняет поручения своего непосредственного руководителя.
3.1.5. ______________________________.
(другие обязанности)
3.2. ________________________________.
(другие положения о должностных обязанностях)
4. Права
4.1. Ведущий программист имеет право:
4.1.1. Участвовать в обсуждении проектов решений, в совещаниях по их подготовке и выполнению.
4.1.2. Запрашивать у непосредственного руководителя разъяснения и уточнения по данным поручениям, выданным заданиям.
4.1.3. Запрашивать по поручению непосредственного руководителя и получать от других работников организации необходимую информацию, документы, необходимые для исполнения поручения.
4.1.4. Знакомиться с проектами решений руководства, касающихся выполняемой им функции, с документами, определяющими его права и обязанности по занимаемой должности, критерии оценки качества исполнения своих трудовых функций.
4.1.5. Вносить на рассмотрение своего непосредственного руководителя предложения по организации труда в рамках своих трудовых функций.
4.1.6. Участвовать в обсуждении вопросов, касающихся исполняемых должностных обязанностей.
4.2. ___________________________.
(иные права)
5. Ответственность
5.1. Ведущий программист привлекается к ответственности:
— за ненадлежащее исполнение или неисполнение своих должностных обязанностей, предусмотренных настоящей должностной инструкцией, — в порядке, установленном действующим трудовым законодательством Российской Федерации, законодательством о бухгалтерском учете;
— правонарушения и преступления, совершенные в процессе своей деятельности, — в порядке, установленном действующим административным, уголовным и гражданским законодательством Российской Федерации;
— причинение ущерба организации — в порядке, установленном действующим трудовым законодательством Российской Федерации.
5.2. _______________________________.
(другие положения об ответственности)
6. Заключительные положения
6.1. Настоящая должностная инструкция разработана на основе Профессионального стандарта «Программист», утвержденного Приказом Министерства труда и социальной защиты Российской Федерации от 18.11.2013
N 679н, с учетом ________________________________.
(реквизиты локальных нормативных актов организации)
6.2. Ознакомление работника с настоящей должностной инструкцией осуществляется при приеме на работу (до подписания трудового договора).
Факт ознакомления работника с настоящей должностной инструкцией
подтверждается ________________________________
(подписью в листе ознакомления, являющемся неотъемлемой
______________________________________________
частью настоящей инструкции (в журнале ознакомления с должностными
______________________________________________
инструкциями); в экземпляре должностной инструкции, хранящемся у
______________________________________________.
работодателя; иным способом)
6.3. __________________________________________.
(другие заключительные положения)
———————————
Информация для сведения:
В соответствии с Профессиональным стандартом «Программист», утвержденным Приказом Министерства труда и социальной защиты Российской Федерации от 18.11.2013 N 679н, иное возможное наименование должности — «ведущий инженер-программист».