Комментарии 44
Спасибо, хорошая статья. О мелочах, которые сам человек не замечает, но которые могут сильно раздражать окружающих.
Стараемся обращать внимание на мелочи :)
дьявол как раз скрывается в мелочах.
Интересно, за что минусы? Кому-то почудилось тут возражение?
Идиоматическое выражение "The devil is in details" означает лишь, что мелочи имеют большое значение.
Идиоматическое выражение "The devil is in details" означает лишь, что мелочи имеют большое значение.
C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM.
Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана. Если все внезапно пошло не так, и надо срочно придумывать, что делать — это факап PM'а.
В реальности, конечно, все чуть сложнее и в небольших конторах с т.з. руководства часто PM еще и продажник, тестер, немного тимлид и еще и курьер по совместителству.
Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана. Если все внезапно пошло не так, и надо срочно придумывать, что делать — это факап PM'а.
В реальности, конечно, все чуть сложнее и в небольших конторах с т.з. руководства часто PM еще и продажник, тестер, немного тимлид и еще и курьер по совместителству.
Пункт про другое. Если у вас дедлайн и разработчикам приходится задержаться, то PM должен задерживаться вместе с ними, в конце концов это его ответственность.
Если не перевру, bobuk вообще предлагал приходить раньше самого первого разраба команды и у ходить позже последнего. Но это как-то перебор.
Если не перевру, bobuk вообще предлагал приходить раньше самого первого разраба команды и у ходить позже последнего. Но это как-то перебор.
Я писал про первую часть, которая некорректно описывает роль PM'а. Если внезапно выясняется, что сдавать проект завтра, а работы осталось по оптимистичным оценкам на три дня — это, естественно, косяк PM'а. Поскольку в проекте протяженностью более недели эта динамика должна быть ясна сильно раньше.
«Приходить раньше первого и уходить после последнего» — это уже что-то из серии «Здесь мерилом работы считают усталость» вместо «Work smart, not hard». Любой член команды должен работать над проектом столько, сколько требуется для его выполнения. Соответственно, пока проект идет по графику — PM уделяет ему столько времени, сколько для этого требуется. Если что-то идет не так — он, естественно, должен потратить больше времени. Но не потому, «чтобы разработчикам не было обидно», а чтобы понять, откуда возникли проблемы, разработать план решения и его реализовать. А то и дизайнера надо заставлять сверхурочно сидеть, несмотря на то, что его работа уже месяц как закончена — иначе программисты обижаются.
«Приходить раньше первого и уходить после последнего» — это уже что-то из серии «Здесь мерилом работы считают усталость» вместо «Work smart, not hard». Любой член команды должен работать над проектом столько, сколько требуется для его выполнения. Соответственно, пока проект идет по графику — PM уделяет ему столько времени, сколько для этого требуется. Если что-то идет не так — он, естественно, должен потратить больше времени. Но не потому, «чтобы разработчикам не было обидно», а чтобы понять, откуда возникли проблемы, разработать план решения и его реализовать. А то и дизайнера надо заставлять сверхурочно сидеть, несмотря на то, что его работа уже месяц как закончена — иначе программисты обижаются.
C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM. Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана.
Опасное заблужение именно для wannabe-пиэма. PM, конечно же должен составить план, но предполагать, что там прописаны действия на все случаи жизни — опасная наивность. Более того, изменения первоначального плана будут обязательно.
В большинстве компаний PM должен держать руку на пульсе ежедневно и именно что быть готовым импровизировать на ходу
Я где-то писал про то, что после написания плана PM самоустраняется? По-моему, я писал только о том, что отклонения должны быть замечены еще до того, как они приводят к серьезным проблемам, и уже на этом этапе предпринимаются корректирующие действия. Для этого, кстати, неамловажен вменяемый фидбек от остальных членов команды. И их понимание того, что желание знать степень готовности задачи — это не придирка «почему так медленно» и не попытка лишить премии, а как раз та самая попытка поиска отклонений.
Очень понравилась статья и особенно пункт «в работу вступает PM, который разбирается в ситуации и находит путь для движения вперед.» разгребать конюшни обычно никто не желает.
Сам сталкивался с каждым пунктом из статьи, спасибо.
Некоторым ПМ стоит эти фразы на лбу вытатуировать, чтоб в зеркале каждый раз читали.
Спасибо!
Спасибо!
Полезно, логично, спасибо. Вроде очевидные вещи, но опыт позволяет выразить их четко и ясно. Я бы так не смог.
НЛО прилетело и опубликовало эту надпись здесь
Кто-то выполняет задачи быстро, а кому-то нужно время подумать.
«Я смотрю, ты уже давно не пишешь код»
Я бы добавил, что стоит оценивать не столько сам факт или время работы, сколько результат за некоторое достаточно большое время.
Потому что результат зависит не от одного действия, а от их совокупности. Работать 9 часов с перерывами обычно более продуктивно, чем без них.
Обращайте внимание не на скорость работы, а на способность «предсказывать», сколько времени потребуется на выполнение задачи. Главное – это то, насколько объективно коллега оценивает свои возможности.
Это не всегда работает, надо учитывать контекст. Если программисту дают задачу исправить ошибку в той части приложения, которой он до этого никогда не занимался, он вряд ли сможет дать правильную оценку, разве что наугад сказать.
НЛО прилетело и опубликовало эту надпись здесь
А иногда бывает дают задачу "добавить еще один фильтр для поиска", скажешь "ну, уйдет дня три на изучение всего что там написано, ну и +- пол дня на реализацию", а тебе в ответ "да там всего-то одно поле ввода добавить" и ведь никто не имеет представления о том, как внутри устроен поиск, как устроена БД, как устроена программная часть...
У меня вот сейчас примерно такая же ситуация. Один человек пилил проект (очень критичный) год, за неделю до отпуска решили этот проект запустить, запустили, оказалось что там, уж простите, нихуя толком не работает, а мне сейчас это допиливать… И многие думают "да чё там поле ввода добавить", при том, что ни дающие задачи, ни я — не имеют совершенно никакого представления о том как все это работает, и то, какой там говнокод...
А бывает подзабудешь какую-нибудь часть системы, в которую год никто не заглядывал…
И берёшь задачу с чувством, что день-то точно потратишь пока разберёшься куда впилить, и возможно ли вообще, или придётся переписывать килобайты кода…
Ан-нет, оказывается тестами эта часть была покрыта хорошо, open-closed соблюдён, задел на расширяемость уже есть. один интерфейсик заимплементил за часик, и всё само зафурчало. Красота.
И берёшь задачу с чувством, что день-то точно потратишь пока разберёшься куда впилить, и возможно ли вообще, или придётся переписывать килобайты кода…
Ан-нет, оказывается тестами эта часть была покрыта хорошо, open-closed соблюдён, задел на расширяемость уже есть. один интерфейсик заимплементил за часик, и всё само зафурчало. Красота.
Все так, мне просто подумалось, что какой-нибудь менеджер начитается таких советов и будет на основе них принимать решение, кого из новых разработчиков оставить после испытательного срока. Новые работники обычно не уточняют, что раньше не занимались проектом, это и так подразумевается.
Программеры чаще всего так и говорят. А вот реальный ответ на такую фразу одного из директоров довольно крупной компании: «Что значит не можешь? В этих процедурах что, select'ы другие какие-то? Делай давай! Быстро!»
В точку. Под каждым словом готов подписаться
Подтверждаю. У нас так 8 часов в день 5 — 7 дней в неделю…
Никогда не задумывался особо на счет подобных фраз, но вообще и впрямь жизненно. Теперь немного неловко за некоторые моменты общения с тестировщиками, но теперь буду знать, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Хорошо написано! Спасибо!
После фразы «Обучение в университете» стал искать тег «перевод». Чтобы стать хорошим программистом, университет не нужен, там максимум «учат учиться». А необходимо — желание и стремление научиться, чему всякие курсы помогут.
по мне так наоборот курсы дают быстрый старт, но в итоге разработчик не знает откуда «курс это узнал». Т.е разработчику дали знания но не сказали где искать новые, а так как он их находил не сам то он тоже не знает.
Согласен.
Нормальный (сознательно не говорю — хороший) программист обязан знать курс «Архитектура ЭВМ», «Операционные системы», «Основы вычислительных сетей», «Базы данных», и хорошо бы еще теорию компиляторов.
Иначе это не разработчик, а непонятно кто, с кашей в голове.
Нормальный (сознательно не говорю — хороший) программист обязан знать курс «Архитектура ЭВМ», «Операционные системы», «Основы вычислительных сетей», «Базы данных», и хорошо бы еще теорию компиляторов.
Иначе это не разработчик, а непонятно кто, с кашей в голове.
Это как минимум. Хорошо бы уметь грамотно составлять требования и техническую документацию, понимать методологии разработки и тестирования, правовые аспекты, уметь планировать проекты, читать документацию на англ языке, знать основные алгоритмы и структуры данных, ОО-дизайн и параллельное программирование. Всему этому в обязательном порядке учат в российских университетах последние лет 20 точно, а также многим другим фундаметальным вещам которые нужны пусть не всем, но необходимы топовым программистам/архитекторам.
Мне кажется это уже на сеньора тянет.
Это Junior, ибо все что я перечислил выше — это лишь теоретические знания)
Senior приходит с опытом практического проектирования, работы в команде, знаниями среды, фреймфорков, систем контроля версий. А также способностью адекватно взаимодействовать с менджментом (напрямую, а не через другого Senior'а). Соответсвенно Senior'а подготовить в университете увы никак не получится.
Senior приходит с опытом практического проектирования, работы в команде, знаниями среды, фреймфорков, систем контроля версий. А также способностью адекватно взаимодействовать с менджментом (напрямую, а не через другого Senior'а). Соответсвенно Senior'а подготовить в университете увы никак не получится.
Что значит знать курс? а что если я не проходил подобный курс, а сам с этим разбирался?
Все эти вещи не нужно говорить и дизайнерам, и верстальщикам… да кому угодно.
Зависит от того, кто будет автором статьи.
Зависит от того, кто будет автором статьи.
НЛО прилетело и опубликовало эту надпись здесь
Отличная статья, спасибо! Добавил в закладки, чтобы можно было делиться ссылкой, когда начинают задавать подобные вопросы.
Добавлю личную историю к пункту №8.
Много лет назад я работала в филиале одной крупной международной компании. Наш отдел делал программный продукт, который на то время был самым сильным в своей области. Его интерфейс был чуть лучше текстового, а опции чуть более продвинутые, чем базовые, включались setenv-ами. Этот интерфейс возник лет за десять до описываемых событий, когда один исследователь решил поковыряться в этой области, и с тех пор не сильно изменился.
Однажды начальству пришло в голову, что неплохо бы сделать нормальный GUI. Эту работу поручили мне. До этого я интерфейсы никогда не разрабатывала. Зато я была прекрасно знакома с программой, в т. ч. как пользователь, и у меня была сильная вера в свои силы.
Я составила список опций базовых/ продвинутых/ очень продвинутых. Опции искала grep-ом в коде, нашла более 200, опросила разработчиков компонент по поводу незнакомых. Долго рисовала эскизы GUI, придумывала визуализацию логов. Потом я пыталась получить мнение членов отдела о моем проекте GUI.
Где-то через неделю после напряженной работы начальник спросил меня:
— Как, ты еще не написала ни строчки кода?
Много лет назад я работала в филиале одной крупной международной компании. Наш отдел делал программный продукт, который на то время был самым сильным в своей области. Его интерфейс был чуть лучше текстового, а опции чуть более продвинутые, чем базовые, включались setenv-ами. Этот интерфейс возник лет за десять до описываемых событий, когда один исследователь решил поковыряться в этой области, и с тех пор не сильно изменился.
Однажды начальству пришло в голову, что неплохо бы сделать нормальный GUI. Эту работу поручили мне. До этого я интерфейсы никогда не разрабатывала. Зато я была прекрасно знакома с программой, в т. ч. как пользователь, и у меня была сильная вера в свои силы.
Я составила список опций базовых/ продвинутых/ очень продвинутых. Опции искала grep-ом в коде, нашла более 200, опросила разработчиков компонент по поводу незнакомых. Долго рисовала эскизы GUI, придумывала визуализацию логов. Потом я пыталась получить мнение членов отдела о моем проекте GUI.
Где-то через неделю после напряженной работы начальник спросил меня:
— Как, ты еще не написала ни строчки кода?
Я пишу панель управления хостингом, основанную на идее контейнеризации, собрав косяки двух топовых платных и нескольких бесплатных панелей управления хостингом в боевом использовании за несколько лет от технической поддержки до хостмастера.
Так вот, я потратил вечера нескольких месяцев, чтобы написать только скриптовую часть, на полгода вообще эту задачу выбросил из головы, и только через полгода я засел за теорию, планирование ТЗ и функционала панели. Обрисовал несколько блокнотов, и только этой зимой сел за RoR и начал писать саму панель управления.
Так вот, я потратил вечера нескольких месяцев, чтобы написать только скриптовую часть, на полгода вообще эту задачу выбросил из головы, и только через полгода я засел за теорию, планирование ТЗ и функционала панели. Обрисовал несколько блокнотов, и только этой зимой сел за RoR и начал писать саму панель управления.
Как-то раньше не заметил этой статьи :(
Фактически этот список не только тестировщику или программисту подходит, а вообще любому IT спецу — к примеру под Админа вообще с минимальными правками :)
Спасибо за статью.
Фактически этот список не только тестировщику или программисту подходит, а вообще любому IT спецу — к примеру под Админа вообще с минимальными правками :)
Спасибо за статью.
Мой PM делает почти все эти пункты))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Молчание – золото»: 13 вещей, которые не стоит говорить разработчикам и тестировщикам