Комментарии 125
кратко, в чем суть поста:
1) угадать что за аббревиатурв ПМ исходя из контекста. например, пистолет макаров не подходит, хотя тогда креатив выглядит забавно.
2) понять наглядно, что форматирование текста с разбивкой по абзацам значительно упрощает чтение, хотя не добавляет понимания сути
3) наглядное представление о том, что кроме абзацев нужно понимание, что аудитория которая будет читать креатив достаточно разнообразна и 99.9% людей понять сходу специфику переживаний автора поста без вводных поясняющих данных, будет сложно.
можно, но сложно.
4) в связи с чем возникает желание: зачем читать это, пытаясь разобраться в потоке мвсли автора, если есть масса других постов, более понятных для осиысления.
Как-то мне понаставили минусов в статье про жёсткие диски. Я там упомянул что те, кто не понимает аббревиатур нецелевая аудитория статьи. Повторю здесь. Если Намбэсэвэн не понимает аббревиатур и не воспринимает текст — значит не следует ему этот текст читать, всё равно не зайдёт.
Если не нравится текст или автор, но нечего ответить по существу, то придираться можно и к запятым и к абзацам и т.п.
Лично я ржал очень сильно. ибо мне постоянно приходится делать подобно описанному в статье. Я так сказать по линии МЧС с клиентами часто работаю — типа срочно нужно разгрести по возможности создав архитектурно красивое решение.
Впрочем такое наблюдается не только тут.
Покажите пример, пожалуйста. А то я в каждой ветке, где прозвучало слово "карма", наблюдаю такие рассуждения, но до сих пор не увидел реального юзера с хотя бы 5 нормально заплюсованными статьями (скажем, от +10), без комментариев с рейтингом ниже -20, и при этом с отрицательной кармой.
К вашим услугам.
Я разве где-то сказал, что что-то пошло не так? Наоборот, все более, чем так: мне льстит быть не по нраву среднего ума кармодрочерам.
Я отвечал на прямой вопрос про «юзера с хотя бы 5 нормально заплюсованными статьями». У меня таковых больше 20, большинство — про созданные и поддерживаемые мной лично OSS библиотеки, используемые в сообществе.
Каким бы уродом я ни был бы в жизни, такой контент мало-мальски образованным и людям был бы интересен; но нет — здешняя публика (успешно) голосует за то, чтобы я не смог опубликовать больше ничего.
В результате, если кто-то хочет почитать про один из самых перспективных языков на русском языке — таковой возможности лишен, потому что когда там у меня руки дойдут сделать раздел на русском в своем блоге — хрен знает.
Обидно ли мне? — За новичков немного да. За обиженных сталкеров, которые мониторят мои комментарии и выставляют им минусы no matter what спустя секунду после создания? — вообще нет.
Я отвечал на прямой вопрос про «юзера с хотя бы 5 нормально заплюсованными статьями».
Но так и не смогли на него ответить, потому как этот прямой вопрос звучал совершенно по-другому: "до сих пор не увидел реального юзера с хотя бы 5 нормально заплюсованными статьями (скажем, от +10), без комментариев с рейтингом ниже -20, и при этом с отрицательной кармой".
Что касается остальной части вашего комментария — публика голосует не за то, чтобы вы не могли писать технические статьи, она голосует за то, чтобы вы не могли оскорблять окружающих в комментариях.
А про "обиженных сталкеров" — знаете такой анекдот, про "но стоило мне всего один раз заняться сексом с козой..."? Вот и за вами идёт слава далеко не про ваши технические умения, будь вы хоть трижды гением.
Еще раз, для особо одаренных: мне насрать на хабр, а в особенности — на местную «публику», заигравшуюся в илитку, и уж подавно — на то, какая там за кем идет слава. Если снежинки желают целовать друг друга в жопы за «+1» в карму — так тому и быть. Есть в интернете места, в которые заходить не так противно.
Право решать, ответил я на вопрос, или нет, предоставьте автору вопроса. Ваше мнение по данному вопросу не сто́ит и ломаного гроша.
мне насрать
целовать друг друга в жопы
Есть в интернете места, в которые заходить не так противно.Конечно есть. В доту, к примеру, можно сыграть — там у школоты примерно на таком же уровне словарный запас развит. Сможете найти общий язык, на тему того, кто с чьей мамкой какие дела делал.
Ваше мнение по данному вопросу не сто́ит и ломаного гроша.Забирайте даром, мне не жалко. Хотите еще мое мнение о вашем мнении получить? Так сказать, два по цене одного.
Спасибо.
Статья: +100, ещё две по +10
Карма: -27
В целом понятно, почему. Но тем не менее оно вот так
Креатив опосредованно «технический», аналогия на аналогии. А, аналогии (извините за повтор) это такой приём, который начинается там, где у автора заканчивается, либо отсутствует возможность выразить мысль.
Спасибо. Повеселился. Узнал в чём-то свои будни, хотя ни разу не в разработке, но с помощью "чайника" приходилось и "компоты варить", и "спирты гнать", и "шнурки гладить" :)
P.S. Современные чайники и не на такое способны.
Вообще если чайник с плоским дном из нержавейки например такой:
То да, разбор чайника и использование только нагревателя для глажки шнурков, вполне себе рокет саинс. Правда для тестов\эксплуатации ручку сложно приделать, придётся из ветки дерева прикреплять как то.
Вы совершенно не правы
Итак есть ТЗ "погладить шнурки"
Из инструментария доступны: Розетка на 220, кран с водой, Эл. Чайник. Ну и сами "шнурки"
Решение: воду в чайник, чайник в розетку. В чайник шнурки.
При достижении температуры тестового образца (руки)
Достаём шнурки и отжимаем.
После чего, аккуратно, ряд к ряду наматываем шнурки на корпус чайника. (С неким должным умением шнурки можно закрепить на корпусе без дополнительных инструментариев, заправив концы под соседние ряды)
Снова включаем чайник, с открытой крышкой… В такой ситуации большинство чайников не выключится при закипании…
Переодически проводим измерения влажности шнуров все те же инструментариев (рука)
В случае выкипания более 25% воды, доливаем свеженькой
При достижении необходимой влажности шнуров (высохли)
Отключить чайник.
Готово…
Неплохо…
… представим, что из всех инструментов разработчик знает только чайник. ПМ ставит задачу проекта — принять роды. Казалось бы при чем тут чайник, но вспоминаем что разраб владеет только чайником. Аналитика нет, или он занят, и нормальный процесс детализации требований невозможен. Хорошо что на старте приходит уточнение, роды надо принять у жирафа. Или у дельфина. Пока непонятно. ПМ пристал как банный лист с требованием дать оценку трудоемкости работ, он не виноват, он без неё не может посчитать стоимость, которую надо отдать сейлзу, чтобы он накрутив маржу озвучил цену договора. Чисто теоретически чайник подходит для принятия родов, но раньше так никто никогда не делал. Что ж, для оценки трудоемкости надо декомпозировать цель на задачи и понять какие другие ресурсы могут потребоваться. Для жирафа наверное нужна стремянка, для дельфина — маска и ласты. Интересно, удастся провести нормальное тестирование, или сразу в продашен? Предположим, для жирафа это займёт 100 часов, а для дельфина 180ч, ну там другая среда и вообще они скользкие. Цена договора определёна, обьявлена и обмыта сейлзом совместно с заказчиком, сроки тоже определены, и что неудивительно — сроки никак не коррелируют с действительностью и всякими там ограничениями типа срока беременности.
Беда ждет всех.
Заказчик с трудом понимает как он будет использовать младенца жирафа. Или дельфина.
Сейлз совершенно не уверен, что проект впишется в бюджет и у него будет бонус.
ПМ ничего не соображает в чайниках, жирафах и дельфинах, но очень надеется что по ходу проекта во всем разберется.
Разработчик… этот в любом случае будет во всем виноват вне зависимости от результата, но опыта ему не занимать, он привык, он прорвется.
Но жирафа жаль. Или дельфина.
Ваш комментарий заслуживает того, чтобы оказаться в самой статье.
ПМ между прочим не лыком шит и знает, что чайник это необходимый инструмент при обращении с жирафами, в литературе описание есть.
"… А у жирафа шея длинная,
Он не умеет травку есть.
Его по морде били чайником..."
www.bard.ru.com/php/print_list.php?id=40038
Жиза. Я как ПМ подпишусь под:
ПМ облажался, потому что боится сказать, что нормальные решения требуют нормального количества времени заказчику.
Сон такого ПМа краток и неспокоен.
Насколько я понимаю, если он скажет, то просто останется без заказчика. Всегда найдётся ПМ, который перечить не будет.
Именно так, рынок лимонов в чистом виде. Нобелевка, кстати…
Проверено лично на Авито — если показывать все «особенности» товара и его недостатки, то никогда не продашь за среднюю рыночную цену, а чаще вообще не продашь.
Единственное, что можно было сказать уже после первого абзаца и закончить это ментальное упражнение.
Слишком у вас всё добро и просто. На понедельник с ПМом договорился… ха!
На деле-то работать придётся все выходные, потому что розетка для кипятильника не работает, мастерим адаптер и подключаем кипятильник к люстре вместо лампочки. Но провод у кипятильника короткий, поэтому макароны варим, стоя на шаткой стремянке и держа чайник на вытянутых руках над головой...
Ссссуууууккаааааа!!! Я не ПМ, и даже не разраб — я "последняя линия техподдержки". Только сегодня пришлось в переговорке подключать новый телевизор (для конференций и демонстрации материалов). Кабель питания недотягивался буквально 15 сантиметров до розетки, а удлинителей свободных нет (да и громоздкий он слишком — вешать на видное место); пришлось резать шнур питания (он несъёмный) и наращивать другим кабелем, благо есть термоусадка, которая неплохо замаскировала место сращения… а вообще, таких "макарон" в проде наварено страшное дело — от подрезания серверного корпуса болгаркой (Контроллер не влезал. Ну и что, что не родной — зато дешевле. Снабженцам виднее) до "гирлянды" точек доступа в режиме повторителя, чтобы на временной промо-кассе в другом конце торгового центра на праздниках билеты продавать.
«Ах вот почему у меня после вашего чая изжога»
Это здорово, если вода в чайнике действительно начнёт закипать через 5 минут, ведь очень часто бывает (постфактум взятия задачи в работу), что чайник занят, на техническом обслуживании или во время кипячения свет неожиданно пропадает, а ещё по мимо задачи сделать чай прилетают: сделать бутерброд, накрыть на стол, зажечь свечи и все эти задачи нужно делать параллельно.
Коротко. Классно. По делу.
Ты говоришь, что чайник только 5 будет закипать
Зависит от объёма требуемого кипятка. Его даже потом можно будет разбавить холодным или молоком и т. д.
Все вот эти менеджеры проектов, руководители проектов как единица управления довольно таки бестолковая, а зачастую и вредная, толковых единицы, бестолковых тьма.
Proof of Concept можно и из говна и палок слепить, он на то и PoC
[… я слышал, что в другом, соседнем колхозе в соседнем районе есть такой пережиток, что ...]«верхи» крайне трудно, плохо, болезненно воспринимают идею что РоС надо выбросить и продукт писать с нуля (особенно если прошло какое-то время) — «у нас же всё готово, Владислав докладывал же, демонстрировали же, основной функционал есть, надо только вот пару мелочей прикрутить». все твои дисклаймеры и «я же предупреждал что это времянка» иногда не идут дальше твоего менеджера (и тоже забываются). В итоге или ты сдаешься, прибиваешь гвоздями требуемое, открывая ворота в ад, или получаешь кучу минусов в карму(в премию, в карьеру), даже если докажешь свою правоту-осадок останется.
Чувствую, что в копилку к «совиному менеджменту» надо добавить ещё и «чайник-менеджмент».
… на завтра чай через 3 минутыЕсли задача формулируется так, то остальное уже не имеет значения.
Правило на самом деле простое.
Есть реальная оценка с упором на максимальное качество, и есть дедлайн.
Если дедлайн ближе реального срока, значит начинается игра "баланс между скоростью и качеством".
Дальше все варианты выливаются управлению, и оно решает что делать:
- Или находим безопасные для качества варианты ускорения
- Или меняем дедлайн
- Или режем набор функциональности без изменения дедлайна
Всё, дальше пусть бизнес решает что ему важнее.
Если менеджер не хочет двигаться по этим вариантам, то это всего лишь значит что он перекладывает выбор решения на разработчиков, потому что ситуация не изменилась, а ультиматум команде поставлен, а значит они или сорвут сроки как и ожидается по реальной оценке, либо сами выберут как ускориться, больше нет вариантов.
В последнем случае просто озвучиваем менеджеру что поскольку решения нет, вы разработчики и обязаны работать на качество (нас за этим берут на работу), то продолжаете работать на качество до принятия решения управлением.
Дальше гнев менеджера (сроки то всё еще срываются), эскалация мол разработчики отказываются работать, разбор полетов, и, скорее всего, казнь менеджера с последующим принятием решения.
Дальше гнев менеджера (сроки то всё еще срываются), эскалация мол разработчики отказываются работать, разбор полетов, и, скорее всего, казнь менеджера с последующим принятием решения.
Это далеко не всегда работает. Менеджер может привлечь других разработчиков (например аутсорс), которые скажут — да не вопрос, сделаем. И что характерно — сделают, возможно даже в срок, но так, что потом это поддерживать будет невозможно.
Ну и еще. У очень многих пост-совковых разработчиков сложилось какое-то странное ощущение, что новые фичи, дедлайны и т.п. это какая-то нелепая прихоть PM-ов или бизнес-команды. А не желание клиентов (которые несут бабки вообще-то, в том числе на зарплату разработчиков). Иными словами, хотелки «чай через 3 минуты» это попытка заработать бабла, и если нужно именно через 3 минуты, то скорее всего через 5 минут денег компания (и ты, мой дорогой разработчик) уже не получишь. Фокус на своей ЗП без понимания того, откуда эта самая ЗП берется — это сразу минус к софт скиллам, прямая дорога к конфликтным ситуациям, ну и потеря в ЗП (т.к. хорошие софт скиллы ведут к более высокой ЗП)
Зона ответственности разработчика не «сроки».
«Сроки» это зона ответственности ПМ.
Программист отвечает за код.
Чтобы он
1) Правильно работал, согласно требованиям
2) Был поддерживаемым. Т.е. чтобы могли взять любого другого программиста такой же квалификации и он мог «сразу» (в идеале 1 спринт во вхождение) работать. А не разбираться в коде по пол года.
Хороший разработчик умеет делать корявый быстрый г0внокод «лишь бы работало», если этого требуют обстоятельства
Есть большая разница в том почему он это делает. Если это решение управления, и других вариантов нет, то, конечно, ему придется это делать. Но это не должна быть "отсебятина в решениях", его задача всегда, пока он может, двигаться в сторону качества.
А не желание клиентов
Наоборот, сроки обычно диктуются бизнес-процессами, но грамотный менеджер умеет на них влиять даже когда это не выглядит возможным, но это возможно, я работал с такими людьми. Есть совершенно четкие алгоритмы как выдержать или сдвинуть срок и при этом не потерять лицо компании, вне зависимости от размера компании клиента.
Но это немного другая опера, на самом деле, потому что управление должно держать руку на пульсе с самого старта проекта, и принимать решения при отклонении от графика или даже ранее, поэтому сама ситуация "мы не успеваем" это либо неверное управление проектом (проект начал проседать, а никто не увидел этого), либо крайне сложная задача поставлена клиентом ("хочу шаттл через 2 недели").
Все моменты, включая потерю кадров, больничные, отпуска, блокеры в реализации, ошибки проектирования, любые риски, всё должно быть в плане проекта, и менеджер всегда должен держать руку на пульсе проекта, для этого и составляется план-график и собираются данные о проекте.
К этому добавляем развитие долгосрочных отношений с клиентом, и на выходе получаем расширенные возможности по движению проекта.
Поэтому здесь снова вопрос не к разработчикам.
«Менеджер умеет влиять на сроки даже когда это не выглядит возможным».
Отлично, поздравляю, а теперь перевернем ситуацию — «хороший разработчик умеет писать код в 10 раз быстрее даже когда это выглядит невозможным».
И не надо про «четкие алгоритмы», хороший разработчик владеет всеми алгоритмами и умеет делать все что надо за любое время, даже наносекунду!
Ваша позиция — это пассивная агрессия и манипуляция, в духе «в смыыыыысле ты сказал что за 3 дня не успеем?! Хороший специалист должен делать невозможное!».
Вы отдаете себе отчет в своей инфантильной позиции в духе «они ответственны вообще за всё, в том числе обязаны делать невозможное, а я тут вообще всегда ни при чем и моя хата с краю?»
Я отдаю полный отчет, и, надеюсь, вы тоже когда-нибудь встретите управленцев, которые умеют проворачивать такие ходы, когда сами клиенты и всё управление остается с открытой челюстью и непониманием как вообще возможно то, что сделали они.
… а вот перевернуть ситуацию нельзя, потому что решения менеджера могут быть приняты за час (с предварительной подготовкой о которой написано выше), а вот разработчик имеет ограниченный физический ресурс.
Если хотите перевернуть, то хороший разработчик не допустит неожиданной полной блокировки работы, потому что перед любой работой идет этап аналитики, где минимум снимаются самые большие технические риски.
P.S. Сбавьте тон, мы здесь не поливаем друг друга грязью или на личности переходим, это ресурс для культурных людей.
Нет, программисты как раз наоборот, в шоколаде от таких решений, потому что дедлайн сдвинут, гонки никто не устраивает, качество не режется, все довольны.)
Тогда надо поднимать вопрос о результатах работы таких кадров, потому что далеко такой поезд не уедет. Как я говорил, выехать за счет разработчиков нельзя, все решения на управлении, а если они не хотят принимать их в пользу компании и команды, то какой смысл от такого управления?
Вам компания из этих фичей деньги платит.
Задача разработчика: отвечать за код и оценки. Если приходит менеджер и просит оценку, ты называешь "Ну месяц", а тебе говорят "Надо за 2 недели или клиент уйдет", то ты отвечаешь "Ну, за 2 недели в принципе можно, но это будет стоить столько-то теходолга которые акунутся так-то". После этого менеджер передает информацию наверх и принимается решение. Не разработчиками, а менеджментом.
Если сказали работать на качество и клиент подождет — ну тут понятно.
Если сказали делаем за 2 недели — ну, делаем, что сами предложили.
Если сказали делать за 2 недели а потом ходят и охают че все так плохо — поднимайте переписки и показывайте, что риски были озвучены, и замедление работы команды вы предсказывали ещё год назад. Если это не помогает и вам действуют на нервы — ну, не работайте с мудаками
то хороший разработчик не допустит неожиданной полной блокировки работы, потому что перед любой работой идет этап аналитики, где минимум снимаются самые большие технические риски.
А потом прилетает изменение приоритетов, очень важная забытая просьба без-которой-релизить-низзя и новое требование от законотворцев(GDPR, например).
И предсказателей будущего и телепатов в разработку почему-то не завезли, и снова начать этап аналитики и перепроектирования почему-то не дают.
Надо полагать, недостаточно хорошие разработчики не смогли в предсказание?
Нет, недостаточно хорошие управленцы не смогли в планирование.)
Если они движутся по критическому пути, и эта проблема вылезла под конец, а ресурсов нет, значит планирование хреновое, риск не учтен.
Слышали про маржевание оценки между слоями в отделе?
Берем оценку разработчиков с рисками, добавляем риски управления, добавляем риски продукта, и получаем нормальный перезаклад на риски. И это только верхнеуровневые риски. Если срабатывает риск на любом уровне, он уже должен быть покрыт. Если этого не произошло, значит кто-то не досчитал.)
Если же прилетела задача размера "аларм, у нас плюс год работы", то это серьезное основание поговорить с клиентом, и пообщаться по поводу решения, может быть сроков, если этот риск не был закрыт ранее.
А на самом деле у меня термопот, потому что я же профессионал. И хороший чай готов через 2 минуты.
Немного оффтоп: мне вспомнился 2007, служба идет, вечер, дед громко: один!!! К деду подбегает дух, дед — чай мне и протягивает кружку. Через минуту чай готов, для деда и духа вечер удался, все довольны. В эту минуту входит: наполнение кружки водой, бросок к специальной тумбочки, где спрятаны чайный пакетик, кипятильник, состоящий из 2 лезвий, между 2 спички — смотано + провод с вилкой. Вода в кружки от этого девайса закипяет за 30 секунд иногда за 25, если воды меньше. Из этого самое сложное донести кипяток с чаем обратно, горячо, руки жжет, но нужно быстро и не разлить. Блин, неграмотный ПМ с барского плеча аж 3 минуты дал, Вы — счастливчик.
А если серьезно, нахер такую, pm прослойку между бизнесом и разработкой.
Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит на Хабре, я отвечу: жалуются на сроки и беспокоятся о карме.
Берётся один стакан с водой, и в него опускается кипятильник мощностью 0,44кВт.
Этих кипятильников готовых — вагон и маленькая тележка, надо просто подобрать чтоб в стакан помещался. А то прилепят всякие блюпупы с файфаями, да так что на столе не помещается. И звонят потом на свой кипятильник, волнуются пля.
А по тесту — все понятно и не раз пережито. Поэтому интереснее писать про оптимизацию приготовления именно чая, именно в придуманных в статье условиях) Ну вот, к примеру, не понятен этот момент — «Кидаешь пакетик в чайник, заливаешь водой и ждешь когда вода покоричневеет.» А что мешает при всем при этом еще и чайник включить/поставить на огонь? Ну понятно что вода закипеть вроде как не успеет, но ведь все мы знаем как оно часто бывает — пока то да се — может и закипит и остынет уже. Ну и раз оказывается у нас есть еще и кипятильник — почему бы его тоже в закипающий чайник не всунуть? Так бы мы как раз в эти самые 3 минуты и уложились бы. Но вместо это, когда ПМ прибегает с холодным чаем назад, мы снова забываем что чайник умеет кипятить и пытаемся кипятить одним кипятильником, в кружке — «Думаешь докипятить долго и находишь готовое решение — старый кипятильник в шкафу. Кидаешь его в кружку, включаешь в розетку, оно греется».
И дальше — мы вообще никак не решаем проблему ускоренного кипячения чая, но почему-то решаем проблему наличия у кипятильника шнура, создавая аккумулятор. Так, как будто от нас именно этого и просили — «Мы же не можем оставить такую зависимость от кабеля...». Хотя у нашего чайника, скорее всего был такой-же шнур, как и у кипятильника. Однако, удивительным образом, мы все-таки вписываемся в «хотелки» заказчика — то ли заказчик очарован нашим решением, то ли пока ПМ донес чай, тот все-таки нагрелся.
Дальше чудеса кулинарии начинаются с макаронами (кстати попутно мы выясняем что у чайника вероятно таки есть шнур) — «Доливаешь воды и включаешь. Проходит минута и ты понимаешь, что макароны воду не красят и как понять, что они готовы будет не так просто.» Эм, а как вы обычно понимаете что макароны готовы? Предлагаю поступать точно так-же, тут реально ничего нового придумывать не нужно, рецепт выверен годами) Более того, рецепт обычно начинается так "В кипящую, подсоленную воду..." — это вот как-раз когда мы пришли с утра, полные сил и ума, и пошли на свой скрам-митинг, чтобы рассказать другим членам команды о своих изобретениях и выслушать их скептические мнения о своих умственных способностях, вот как раз тогда и нужно было поставить эту самую воду закипать. Заодно и рецепт уточнить и узнать что воду можно кипятить заранее и чтобы ускорить — вполне можно было кипятильник совместить с чайником, а не удлинять время и снова наливать воду в холодное ведро и кипятить аккумулятором по дороге. Ведь «задача та стояла — сварить их и быстро». Да и пояснение, оставленное заказчику, оставляет желать лучшего — «ведро не открывать пока подключен аккумулятор» — как же мы узнаем что вермишель готова? Так можно вермишель и переварить и недоварить и высушить вообще, если вода выкипит. Да и вообще, по сути мы отдаем заказчику конструктор, который он должен дособирать сам — сомнительная победа. Думаю после этого нужно будет искать нового заказчика)
А вообще — да, именно поэтому я уже давно варю дома вермишель себе сам, варю сколько хочу и как хочу, и не на время, а на удовольствие)
Тут уже все зависит от умения программиста правильно «наехать» на ПМа, и умения ПМа признавать свои пробелы в знаниях и прислушываться к советам низлежащих по званию.
Удивительно другое, что такая фигня творится обычно только на клиентских проектах. Когда команда разрабатывает свой продукт, то менеджер продукта обычно так не делает. Потому что когда у тебя тысяч 100 платящих пользователей, которые из-за косяков в новом релизе могут внезапно перестать быть таковыми, начинаешь очень хорошо все продумывать.
И ещё момент, очень часто разработчики не понимают, что руководитель проекта это функциональная роль, а не уровень подчинённости. РП не является начальником разраба. Почему разраб не стесняется своему коллеге на код ревью указывать на плохие места и не аппрувить пулл-реквест, а послать менеджера проекта думать дальше стесняется?
Любая новая фича это всегда баланс между «улучшить что-то и нам будут платить больше», «не попасть в ожидания и платить будут меньше» и «случайно всё сломать нафиг, потому что задеплоили с багами»
имхо, сколько времени разработчику софта не выдели, он потратит в три раза больше, по этому при постановке задачи делю время на пи…
с железом сложнее, там есть цикл производства, но то же учитывается…
ps: очень сложно, когда в коллективе умеют только отдельно или чайники, или кипятильники, или макароны… ))) кто-то скручивает кипятильник, кто-то опускает его в чайник, кто-то варит макароны и все говорят, что времени мало, но ждут, ничего не делая, завершения предыдущего этапа)
открыв чайник тебя наполняет крайнее удивление
«Подъезжая к сией станцыи и глядя на природу в окно, у меня слетела шляпа» А.П.Чехов
Знакомая история. Можно было еще глубже копнуть про легаси с самоваром)))
Что-бы увеличить прибыль проекта — надо меньше платить разработчикам и ставить им более сжатые сроки!
берём два советских лезвия для бритвы, зажимаем между ними пару спичек на концах, фиксируем конструкцию синей изолентой и нитками поверх. Спички не должны вылетать, это важно! Подключаем к двум лезвиям два провода, провода — в розетку, конструкцию — в стакан с водой.
Вода вскипает почти моментально.
Евгений Степанищев
Эксперт
Описанные моменты можно охарактеризовать как «Маразм крепчал» :)
Спасибо за статью:)
А потом, поработав пару месяцев, ты понимаешь, что эта команда просто по-другому не умеет. И даже получает определенное удовольствие от такого ХХП-образного стиля принятия решений. И не хочет включать мозг, всех все устраивает, а самый старший разработчик вообще ручным парсером JSON подрабатывает.
При этом все читают кое-какое.it, рассуждают исключительно сленгом оттуда (галеры, гребцы и т.п.). А что такое циклическая ссылка — зачем, у нас нет времени, видишь — срок заказчик поставил.
На заявление ПМ-а «Нужен чай через 3 минуты» ты всё быстро обдумываешь и выдаёшь: «Через 3 минуты чая точно не будет, но могу выдать что-то жёлтое в литровой банке. Ну или такое-же по вкусу но Липтон, через 10 минут. Ну или реально вкусный Шу-Пуэр, но через 2 часа.»
ПМ доносит это до клиента, попутно уточняя нюансы: «Цвет чая, лимон, молоко, сахар» (по твоей просьбе), клиент соглашается на завтрашнее утро.
Ты, довольный, к утру выдаёшь ПМ-у термос вкуснющего, протестированного чаю. А потом он возвращается к тебе и говорит что вы оба уволены…
В афиге просишь объяснений и оказывается что чай-то нужен был на вечер а не на утро, и твой термос давно остыл, да и вообще, клиент не уточнил что чай он будет пить не сам, а в компании ещё 200 гостей банкета, а хватило только на 2-х…
У меня бывает обычно так:
ПМ: Нужен чай.
Я: Какой чай, на сколько человек, какой крепости, с молоком/без, с сахаром, нужен лимон. Чай черный/зеленый или какой?
ПМ: Я уточню
Через три месяца
ПМ: Нам нужен чай — сроки горят. Вроде бы зеленый без сахара, на максимальное количество человек
Я: Ок. Зеленый чай и сахар купили?
ПМ: Нет. Сделай сам.
Я: Ок. Приходите через пару лет. Надо вырастить чай и свеклу. Если свеклу ещё быстро можно вырастить, то с чаем проблема, может и не вырасти в наших широтах.
ПМ: Нельзя у нас сроки горят
Я: Ну ок. Что-нибудь придумаем.
Варим какую-то бурду из «помойки»
<:o)
Приходит ПМ и говорит, что надо на завтра чай через 3 минуты