Pull to refresh

Приходит ПМ и говорит, что надо на завтра чай через 3 минуты

Reading time 4 min
Views 69K

ПМ - Project manager (руководитель проекта).

Ты говоришь, что чайник только 5 будет закипать. ПМ настаивает, что клиент очень просит и это нам крайне важно, ты под натиском прогибаешься и решаешь что-то думать. Кидаешь пакетик в чайник, заливаешь водой и ждешь когда вода покоричневеет. Четко понимаешь, что надо будет не забыть отмыть чайник, ибо так останутся кольца от чая и возможно плесень. Наливаешь получившуюся крашеную воду для клиента, ПМ с довольной рожей говорит: ну видишь, можно же. А ты думаешь, что не хотел бы что бы тебе так делали... Но обстоятельства требуют. И только ты расслабился, как влетает ПМ и говорит: ты хоть пробовал это?

Ты осознаешь что походу вкуса нет... Пробуешь оправдаться, но тут ПМ тебя перебивает и говорит: да при чем тут вкус, он же не кипяток и ты быстро начинаешь думать что делать. Думаешь докипятить долго и находишь готовое решение - старый кипятильник в шкафу. Кидаешь его в кружку, включаешь в розетку, оно греется, а ПМ на тебя смотрит и говорит: кхм... Мы же не можем оставить такую зависимость от кабеля... И ты понимаешь что решение неплохое просто надо допилить, наивно полагая что ты пошел в правильном направлении. Ты находишь аккумулятор, подсоединяешь, и вот все работает, хоть тут даже ПМ осознает, что тут что-то не так. И тут прилетает интрига... ПМ-а нету час, два... Ты начинаешь думать что они или обсуждают твое увольнение, или ПМ-а где-то потеряло, может он уже сам решил допилить. Но тут влетает ПМ и без капли объяснения говорит: клиент очень доволен, надо так же быстро сделать макароны. Ты в недоумении - мол да ладно, оно сработало, идешь и смотришь на чайник и думаешь, а что еще в нем можно сделать. Но так как это вечер пятницы, думаешь, что хватит с тебя таких приключений и договариваешься с ПМ-ом на понедельник.

Вот он понедельник. Ты полон сил и переспав с осознанием, что натворил в пятницу, вспоминаешь про макароны. Без задней мысли всыпаешь макароны в чайник. Доливаешь воды и включаешь. Проходит минута и ты понимаешь, что макароны воду не красят и как понять, что они готовы будет не так просто. Но... открыв чайник тебя наполняет крайнее удивление. Макароны действительно покрасили воду. Но запах чая возвращает тебя в реальность где ты вспоминаешь свое TODO: помыть чайник. С учетом, что времени нет, потому что ПМ сейчас опять прилетит, ты перемешиваешь эту чепуху и думаешь - да ладно, задача та стояла - сварить их и быстро, а не цвет, запах, спишем на неточно данные технические требования. Но тут ты понимаешь, что макарохи совсем не чай и привинтить к ним кипятильник, что бы пока несли их они дошли - не вариант, потому что клиент поймет что это суп, а не макароны. Что бы не портить всю малину ты кипятишь кипятильником вторую воду, но уже в ведре на половину полном. Казалось бы: что здесь происходит, но нет, идея тут все же есть. Ведро накрываем дуршлагом выливаем чайник с коричневыми макарохами в дуршлаг и накрываем крышкой, паром макарохи дойдут до клиента в доваренном виде. Влетает ПМ, ты говоришь с довольным лицом, что все готово, вручаешь ему ведро с крышкой, кипятильник, аккумулятор. У ПМ-а радость на лице плавно перетекает в удивление или шок, но вроде недовольства невидно. Он говорит: “ну ладно” и забирает ведро. Ты явно осознаешь что это все плохо кончится и пока есть свободное время обновляешь резюме, но ПМ-му говоришь о нюансах: ведро не открывать пока подключен аккумулятор - категорически нельзя.

Спустя некоторое время приходит новый разработчик и видит это все:

  • Чайник, ведро, дуршлаг, кипятильник и аккумулятор.

  • Логичные вопросы назревают в голове разработчика:

  • Зачем кипятильник, когда есть чайник.

  • А не убьет кого-то аккумулятором.

  • Почему чайник внутри черный.

  • Какой шанс если плохо нести ведро - кипятильник утонет, коротнет и все взорвется.

  • И классические вопросы: как это вообще работало, так как ни документации, ни старого разработчика и второй вопрос зачем так было делать.

Можно продолжать, но давайте сделаем некоторые выводы уже:

  • ПМ облажался, потому что боится сказать, что нормальные решения требуют нормального количества времени заказчику.

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

  • TODO: - делаются тогда, когда реально в этом месте что-то вылезет или очень редко. У тебя либо сразу есть время сделать нормально, либо оно и потом не появится. Но бывают исключения.

  • Похожие процессы иногда могут требовать совершенно разных подходов. И иногда нормальное решение лежит совсем рядом.

  • Страх - самый большой наш враг и из-за него появляются недоговорки, отмазки, страх признать, что ты человек и быстрее чем “свое быстро” ты нормально не сделаешь, страх сказать заказчику, что нам нужно точное техническое документирование и конкретные требования, страх спросить у более опытного, на форуме или семинаре. Разработчики ходят на семинары, и реально половина не понимает зачем. Да рассказывают, так спроси если не понял, этот эксперт и выступает что бы люди поняли, чтобы увидели больше.

  • Отсутствия опыта формируют костыли, которые часто заставляют нас делать решения, которые полностью ведут нас в неправильном направлении. Как корабль: недосмотрел где полюс, ошибся на 2-3 градуса, вроде мелочь, но через неделю движения в этом направлении, это могут быть сотни, а то и тысячи километров, что бы поправить этот косяк.

  • Разработчики часто думают, что ПМ умен и все проблемы - его проблемы. Но он тоже человек и тоже может ошибаться. Ему тоже надо помогать и подсказывать как правильно и почему что-то может пойти не так.

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

Tags:
Hubs:
+164
Comments 125
Comments Comments 125

Articles