Комментарии 44
Спасибо, хорошая статья. О мелочах, которые сам человек не замечает, но которые могут сильно раздражать окружающих.
Интересно, за что минусы? Кому-то почудилось тут возражение?
Идиоматическое выражение "The devil is in details" означает лишь, что мелочи имеют большое значение.
Это волновые минусаторы. Один ставит минус, другой ставит потому что, кто то уже поставил.
C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM.
Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана. Если все внезапно пошло не так, и надо срочно придумывать, что делать — это факап PM'а.
В реальности, конечно, все чуть сложнее и в небольших конторах с т.з. руководства часто PM еще и продажник, тестер, немного тимлид и еще и курьер по совместителству.
Пункт про другое. Если у вас дедлайн и разработчикам приходится задержаться, то PM должен задерживаться вместе с ними, в конце концов это его ответственность.

Если не перевру, bobuk вообще предлагал приходить раньше самого первого разраба команды и у ходить позже последнего. Но это как-то перебор.
Я писал про первую часть, которая некорректно описывает роль PM'а. Если внезапно выясняется, что сдавать проект завтра, а работы осталось по оптимистичным оценкам на три дня — это, естественно, косяк PM'а. Поскольку в проекте протяженностью более недели эта динамика должна быть ясна сильно раньше.
«Приходить раньше первого и уходить после последнего» — это уже что-то из серии «Здесь мерилом работы считают усталость» вместо «Work smart, not hard». Любой член команды должен работать над проектом столько, сколько требуется для его выполнения. Соответственно, пока проект идет по графику — PM уделяет ему столько времени, сколько для этого требуется. Если что-то идет не так — он, естественно, должен потратить больше времени. Но не потому, «чтобы разработчикам не было обидно», а чтобы понять, откуда возникли проблемы, разработать план решения и его реализовать. А то и дизайнера надо заставлять сверхурочно сидеть, несмотря на то, что его работа уже месяц как закончена — иначе программисты обижаются.
C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM. Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана.


Опасное заблужение именно для wannabe-пиэма. PM, конечно же должен составить план, но предполагать, что там прописаны действия на все случаи жизни — опасная наивность. Более того, изменения первоначального плана будут обязательно.
В большинстве компаний PM должен держать руку на пульсе ежедневно и именно что быть готовым импровизировать на ходу
Я где-то писал про то, что после написания плана PM самоустраняется? По-моему, я писал только о том, что отклонения должны быть замечены еще до того, как они приводят к серьезным проблемам, и уже на этом этапе предпринимаются корректирующие действия. Для этого, кстати, неамловажен вменяемый фидбек от остальных членов команды. И их понимание того, что желание знать степень готовности задачи — это не придирка «почему так медленно» и не попытка лишить премии, а как раз та самая попытка поиска отклонений.
отклонения должны быть замечены еще до того, как они приводят к серьезным проблемам

И именно для этого нужно следить за выполнением работ в ежедневном режиме. При этом понятно, что пытаться прописать в плане все возможные неполадки и подземные стуки неразумно.
Очень понравилась статья и особенно пункт «в работу вступает PM, который разбирается в ситуации и находит путь для движения вперед.» разгребать конюшни обычно никто не желает.
Некоторым ПМ стоит эти фразы на лбу вытатуировать, чтоб в зеркале каждый раз читали.
Спасибо!
Полезно, логично, спасибо. Вроде очевидные вещи, но опыт позволяет выразить их четко и ясно. Я бы так не смог.
НЛО прилетело и опубликовало эту надпись здесь
Кто-то выполняет задачи быстро, а кому-то нужно время подумать.
«Я смотрю, ты уже давно не пишешь код»

Я бы добавил, что стоит оценивать не столько сам факт или время работы, сколько результат за некоторое достаточно большое время.
Потому что результат зависит не от одного действия, а от их совокупности. Работать 9 часов с перерывами обычно более продуктивно, чем без них.

Обращайте внимание не на скорость работы, а на способность «предсказывать», сколько времени потребуется на выполнение задачи. Главное – это то, насколько объективно коллега оценивает свои возможности.

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

Тогда об этом надо так и сказать — «Я до этого никогда не занимался этой частью проекта, поэтому не смогу дать адекватную оценку трудозатрат на эту задачу». Очень часто бывает, что человек не хочет показаться плохим специалистом и говорит что-то вроде «да ерунда, разберусь, за день сделаю», а результата нет и через месяц.

А иногда бывает дают задачу "добавить еще один фильтр для поиска", скажешь "ну, уйдет дня три на изучение всего что там написано, ну и +- пол дня на реализацию", а тебе в ответ "да там всего-то одно поле ввода добавить" и ведь никто не имеет представления о том, как внутри устроен поиск, как устроена БД, как устроена программная часть...


У меня вот сейчас примерно такая же ситуация. Один человек пилил проект (очень критичный) год, за неделю до отпуска решили этот проект запустить, запустили, оказалось что там, уж простите, нихуя толком не работает, а мне сейчас это допиливать… И многие думают "да чё там поле ввода добавить", при том, что ни дающие задачи, ни я — не имеют совершенно никакого представления о том как все это работает, и то, какой там говнокод...

А бывает подзабудешь какую-нибудь часть системы, в которую год никто не заглядывал…
И берёшь задачу с чувством, что день-то точно потратишь пока разберёшься куда впилить, и возможно ли вообще, или придётся переписывать килобайты кода…
Ан-нет, оказывается тестами эта часть была покрыта хорошо, open-closed соблюдён, задел на расширяемость уже есть. один интерфейсик заимплементил за часик, и всё само зафурчало. Красота.
Все так, мне просто подумалось, что какой-нибудь менеджер начитается таких советов и будет на основе них принимать решение, кого из новых разработчиков оставить после испытательного срока. Новые работники обычно не уточняют, что раньше не занимались проектом, это и так подразумевается.
Программеры чаще всего так и говорят. А вот реальный ответ на такую фразу одного из директоров довольно крупной компании: «Что значит не можешь? В этих процедурах что, select'ы другие какие-то? Делай давай! Быстро!»
Никогда не задумывался особо на счет подобных фраз, но вообще и впрямь жизненно. Теперь немного неловко за некоторые моменты общения с тестировщиками, но теперь буду знать, спасибо.
Вот только иногда разработчики не начинают исправлять ошибки, пока их конкретно носом не тыкнешь в то, что это ДЕЙСТВИТЕЛЬНО делается быстро.
Из примера — нам поставили какую-то стороннюю многометровую либу для печати HTML, которая не корректно работала на одном XP. Я за несколько часов набросал свой вариант решения, после того, как разрабы отказались делать сами что-либо (причем ссылались на ТЗ, за что мне пришлось их еще тыкать, что в ТЗ XP — прописан).
В результате, через день-два после небольшого перебранки в почте — я продемонстрировал свой exe на с++, наше руководство прописало им живительных люлей, после чего они таки взяли и написали все сами, при этом заодно заново собрав все шишки, которые по пути выявились, вместо того, чтоб взять использовать готовое.

Другой пример, что в другой компании до сих пор баг с тем, что они не обнуляют переменные перед повторными расчетами. Суть в том, что два разных материала могут зависеть друг от друга, причем увеличение одного уменьшает другой. Естественно, что количество не может быть отрицательным, поэтому в этом случае его обнуляют. Только явно тем, что суммируют с тем же числом, противоположным по знаку. После чего, если ты уменьшаешь первый материал, то второй начинает увеличиваться уже от нуля, то есть он продолжает суммироваться с числом, равным по значению предыдущему округлению. Ошибки полтора года. Меня никто не убедит, что это — гигантское количество времени на исправление.

Так что да, заказчикам иногда приходится указывать программистам, что некоторые моменты — делаются действительно быстро.
После фразы «Обучение в университете» стал искать тег «перевод». Чтобы стать хорошим программистом, университет не нужен, там максимум «учат учиться». А необходимо — желание и стремление научиться, чему всякие курсы помогут.
по мне так наоборот курсы дают быстрый старт, но в итоге разработчик не знает откуда «курс это узнал». Т.е разработчику дали знания но не сказали где искать новые, а так как он их находил не сам то он тоже не знает.
Согласен.
Нормальный (сознательно не говорю — хороший) программист обязан знать курс «Архитектура ЭВМ», «Операционные системы», «Основы вычислительных сетей», «Базы данных», и хорошо бы еще теорию компиляторов.
Иначе это не разработчик, а непонятно кто, с кашей в голове.
Это как минимум. Хорошо бы уметь грамотно составлять требования и техническую документацию, понимать методологии разработки и тестирования, правовые аспекты, уметь планировать проекты, читать документацию на англ языке, знать основные алгоритмы и структуры данных, ОО-дизайн и параллельное программирование. Всему этому в обязательном порядке учат в российских университетах последние лет 20 точно, а также многим другим фундаметальным вещам которые нужны пусть не всем, но необходимы топовым программистам/архитекторам.
Это Junior, ибо все что я перечислил выше — это лишь теоретические знания)
Senior приходит с опытом практического проектирования, работы в команде, знаниями среды, фреймфорков, систем контроля версий. А также способностью адекватно взаимодействовать с менджментом (напрямую, а не через другого Senior'а). Соответсвенно Senior'а подготовить в университете увы никак не получится.
Что значит знать курс? а что если я не проходил подобный курс, а сам с этим разбирался?
Значит ты можешь пройти котроль по этому курсу (тест/экзамен). Т.е. Открываешь программу курса, если все пункты знаешь, значит знаешь курс.
Все эти вещи не нужно говорить и дизайнерам, и верстальщикам… да кому угодно.
Зависит от того, кто будет автором статьи.
НЛО прилетело и опубликовало эту надпись здесь
Отличная статья, спасибо! Добавил в закладки, чтобы можно было делиться ссылкой, когда начинают задавать подобные вопросы.
Добавлю личную историю к пункту №8.

Много лет назад я работала в филиале одной крупной международной компании. Наш отдел делал программный продукт, который на то время был самым сильным в своей области. Его интерфейс был чуть лучше текстового, а опции чуть более продвинутые, чем базовые, включались setenv-ами. Этот интерфейс возник лет за десять до описываемых событий, когда один исследователь решил поковыряться в этой области, и с тех пор не сильно изменился.

Однажды начальству пришло в голову, что неплохо бы сделать нормальный GUI. Эту работу поручили мне. До этого я интерфейсы никогда не разрабатывала. Зато я была прекрасно знакома с программой, в т. ч. как пользователь, и у меня была сильная вера в свои силы.

Я составила список опций базовых/ продвинутых/ очень продвинутых. Опции искала grep-ом в коде, нашла более 200, опросила разработчиков компонент по поводу незнакомых. Долго рисовала эскизы GUI, придумывала визуализацию логов. Потом я пыталась получить мнение членов отдела о моем проекте GUI.

Где-то через неделю после напряженной работы начальник спросил меня:
— Как, ты еще не написала ни строчки кода?
Я пишу панель управления хостингом, основанную на идее контейнеризации, собрав косяки двух топовых платных и нескольких бесплатных панелей управления хостингом в боевом использовании за несколько лет от технической поддержки до хостмастера.
Так вот, я потратил вечера нескольких месяцев, чтобы написать только скриптовую часть, на полгода вообще эту задачу выбросил из головы, и только через полгода я засел за теорию, планирование ТЗ и функционала панели. Обрисовал несколько блокнотов, и только этой зимой сел за RoR и начал писать саму панель управления.
Как-то раньше не заметил этой статьи :(
Фактически этот список не только тестировщику или программисту подходит, а вообще любому IT спецу — к примеру под Админа вообще с минимальными правками :)

Спасибо за статью.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

1 августа 2012 г.

Местоположение

Россия

Сайт

1cloud.ru

Численность

31–50 человек

Дата регистрации

22 мая 2014