Comments 48
В отличие от зверей из дикой природы, они не помирают от этого, но — о чудо! — начинают активнее работать
Работать над поиском другой работы.
Иногда действительно надо поменять ещё тыщу кнопок на зеленые, потому что они все отображают одно и то же.
Мне вообще не понятно, зачем идти на конфликт когда в середине проекта появляются новые, не оговорённые заранее требования. Если о зелёной кнопке не было известно с самого начала, виноват в этом варан. И в 99% случаев, если за ним так же походить и понаблюдать, то очень быстро выяснится что без этой зелёной кнопки можно вообще обойтись.
Или как в материале 2 кнопки обычная и акцент.
И тебя просят сделать ещё пару кнопок, совсем другого дизайна, которые ничего не наследуют и совсем не похожи. И их только 2 и 2-х разных страницах.
И начинаются костыли вроде инлайновых стилей и т.п.
Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.— Ура! Я знал что разработка порталов и сверхсветовых двигателей выполнимая задача!
Обычно когда говорят «Это невозможно!» имеют в виду что то вроде:
— Это невозможно с текущим бюджетом!
— Это невозможно в указанные сроки!
— Это действительно невозможно ибо противоречит здравому смыслу и/или физическим законам и/или законодательству и т.д. и т.п.
— А давай ты на завтра сделаешь перевод на все языки мира, прикрутишь карту, и интеграцию с десятью самыми популярными платежными системами.
Ведь не бывает невыполнимых задач!
Дайте мне 400.000$, 200 опытных специалистов — сделаем.Ведь все возможно!
Хотя за часть этой суммы можно нанять несколько хороших юристов, которые все разъяснят менеджеру с такими задачами, и он сам поймет как ошибался. )
либо надо… одного действительно хорошоего специалиста. Из комикса 'как выучить C++ за 21 день'
Хотя… перевод на все языки? А вам точно нужны ВСЕ языки? 103 языков поддерживаемых Google Translate не хватит? А для первой версии?
Платежные системы популярные где именно? Со своей стороны могу сделать 'тяп-ляп-в-п-продакшн' интеграцию с (например) Interkassa или другим агрегатором а уж они поддерживают много что. Если задержки будут — то по вине самой интеркассы (потребуется их быстро убедить включить нас).
А кстати мы вообще имеем право стороннюю платежную систему цеплять в нашем мобильном приложении?
Вспоминается один переводной фантастическй рассказ где именно таким способом заставили группу ученых сделать антиграв (показали демонстрацию а потом сказали что ученый погиб).
Да, предоставили ресурсы и поддержку.
А еще — Хайнлайн (Время для звезд) вспоминается — получили возможность передавать информацию мгновенно, немного (канал в байты в секунду и увеличить — никак). Сам по себе способ не особо скажем так ценный хотя можно в особых случаях использовать но смысла нет. В пределах Земли померяли (а там еще были с самим каналом сложности — микрозадержки не замерить) — да — вроде мгновенно.
Использовали эту возможность в другом проекте и померяли на расстоянии в световые годы и когда один из объектов — на околосветовой скорости. Да — мгновенно. Итог вообщем понятный — на Землю все участники эксперимента вернулись раньше срока и существенно быстрее чем думали.
А с зеленой кнопкой пример… а что если — программист знает быстрое решение, правда кривое и оно значит что размер приложения вырастет на 5kb x количество кнопок в приложении (а кнопок — сотни) но… это вполне допустимо потому что у нас приложение (единственное на девайсе) ставится на девайс либо на заводе либо при первоначальной настройке (и девайс все равно кабелем подключен)? Программист просто искал (и не нашел) нормальное универсальное решение а тут можно грязный хак сделать. (правда вот что будет если потом таки выяснится что менеджер№2 внезапно решил что а давайте все же выложимся в Google Play а не только для наших специализированных устройств?)
У меня был случай — я пишу заказчику оценку на пару человеко-лет (и там есть пункты — iOS-версия будет работать только на джейлбрейкнутом устройстве + mobilesubstrate потому что то что заказчик хочет — прямо нарушает п.x.y developer agreement и Public API для того что он хочет — нет а для андроида — как бы вообще не пришлось собирать свою прошивку (со всеми проблемами с зоопарком устройств)) а реально: на android все через public api без рута работало, на iOS же… заказчик прямо сказал что приложение будет ставиться через Enterprise Distribution а про функционал — пользователи в курсе вполне будут и согласны, а технически выяснилось что на той версии iOS что была нужна — задача таки решается, через Private API (пришлось взять в зубы IDA для исследования). (Правда заказчик согласился оплатить исследование на тему 'а как это решать вообще в объеме до N' часов).
Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.
А потом тратить на 20 минут больше на каждую связанную задачу для каждого нового разработчика. Или час. Или день.
И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.
Вот дура, заладила блин, не понимает логичных объяснений. Ладно, сделаю костыль, чтобы хоть как-то работало, сами потом придут когда поймут в чем ошибка. А может и вовсе забудут.
потом тратить на 20 минут больше на каждую связанную задачу для каждого нового разработчика. Или час. Или день.
Или не тратить вовсе, поскольку, в отличии от этого говнокодера, архитектор был умный и разработал нормальную архитектуру приложения в которой не надо тратить неделю на цвет кнопки, но, говнокодер привык относиться к своему коду, как к сборищу костылей и не видит даже этого :).
разработал нормальную архитектуру приложения
Так речь же о том, что времени на это нет.
Речь о прокрастнации вообще-то. А если нормальной архитектуры нет, то имеются костыли говнокодера и говнокодеры же обвиняют менеджера в своём говнокодстве.
На картинке обсуждается решение задачи, а не безделье работника.
Откуда по-вашему возьмется нормальная архитектура, если менеджер требует решать задачи за 20 минут?
На картинке обсуждается решение задачи, а не безделье работника
А вы текст-то прочитали?
Откуда по-вашему возьмется нормальная архитектура, если менеджер требует решать задачи за 20 минут?
Менеджер требует решить за 20 минут одну конкретную задачу, которая решается за 20 минут, если говнокодер до этого не наговнокодил, а сделал как положено. На "сделать как положено" выделяется не 20 минут.
На «сделать как положено» выделяется не 20 минут.
Так бывает?))
В тексте говорится, что менеджер почему-то считает желание разработчика сделать грамотное решение задачи с продуманной архитектурой прокрастинацией.
Менеджер требует решить за 20 минут одну конкретную задачу, которая решается за 20 минут, если говнокодер до этого не наговнокодил, а сделал как положено.
Откуда известно, что задача решается за 20 минут, если специалист дает оценку в несколько дней?
По описанию ситуации предполагается, что проект имеет приемлемое качество. Значит ни о каком "говнокоде до этого" речь не идет. Программист прямо говорит, что при правильном решении на задачу нужно несколько дней, что за 20 минут будут костыли. Менеджер все равно требует решить задачу за 20 минут. Именно в этот момент появляется говнокод. Который и создает проблемы в будущей поддержке.
А если на момент ситуации говнокод уже был, значит эта ситуация повторялась ранее с другой задачей.
На "сделать как положено" выделяется не 20 минут.
Именно это и собирался сделать программист на картинке. Потому что "делать как положено" надо всегда в любой задаче.
В тексте говорится, что менеджер почему-то считает желание разработчика сделать грамотное решение задачи с продуманной архитектурой прокрастинацией
В тексте говорится, что говнокодер накодил настолько кривые костыли, что для выполнения простейшей задачи ему требуется совершить героический подвиг.
Откуда известно, что задача решается за 20 минут, если специалист дает оценку в несколько дней?
Потому что задача по изменению цвета кнопки не может решаться несколько дней ни при каких обстоятельствах. А если говнокодер утверждает, то это ему нужна неделя, то ему место на бирже труда в очереди за рисовой похлёбкой. Специалистом он не может считаться ни коим образом.
По описанию ситуации предполагается, что проект имеет приемлемое качество
Йес,! Менеджер предполагает, что проект имеет приемлимое качество. Оказывается, это не так. Оказывается, изменение цвета кнопки может разрушить цивилизацию. Это не приемлимое качество. Это — говнокод в чистом виде.
Именно это и собирался сделать программист на картинке
Это нужно было делать на предыдущем этапе. На этом этапе — гнать дебила в шею с волчьим билетом.
В тексте говорится, что говнокодер накодил настолько кривые костыли
Где именно? Про качество там вообще ничего не говорится.
Потому что задача по изменению цвета кнопки не может решаться несколько дней ни при каких обстоятельствах.
Изменение цвета это просто пример. Я говорил о подобных ситуациях в целом. Когда программист говорит, что надо времени N, а менеджер говорит, что надо N/100. А вовсе не про кнопки.
Если рассматривать конкретно эту задачу, то программист, который интегрировал бутстрап и пару плагинчиков, в принципе не стал бы говорить, что нужна неделя, а просто добавил бы правило в CSS. Но если рассматривать аналогичную задачу для desktop, то там уже не так все просто. Ресурсы по отрисовке кнопки с темой оформления могут находиться в dll, и чтобы что-то изменить, надо будет писать обвязку для нее.
Менеджер предполагает, что проект имеет приемлимое качество. Оказывается, это не так. Оказывается, изменение цвета кнопки может разрушить цивилизацию.
В любом проекте есть вещи, которые нельзя изменить за 20 минут. Про любую из них можно сказать "Оказывается, изменение %this_thing% может разрушить цивилизацию". Значит ли это, что любой проект плохо написан? Нет.
Это нужно было делать на предыдущем этапе.
Почему менеджер не может так себя вести на предыдущем этапе? Более того, в тексте прямо говорится, что менеджер должен так делать всегда. И мой коммент был о том, к чему может привести такое поведение — к хреновому коду во всем проекте.
менеджер должен следить за работой разработчика или дизайнера. программистам это только поначалу неприятно. дальше, как ни странно — человек втягивается и выравнивается. и в итоге оказывается, что вместо недели задачу можно решить за… или 20 минут.
Где именно? Про качество там вообще ничего не говорится.
Потому что настолько простая задача не должна рушить цивилизацию. Если рушит, значит в консерватории что-то не то.
Изменение цвета это просто пример. Я говорил о подобных ситуациях в целом.
В данном случае это пример простой задачи, которая при любом раскладе не должна приводить к катастрофе. Если бы стояла цель демонстрации подхода к сложной задачи, то пример был бы другим. Разве это не очевидно?
Но если рассматривать аналогичную задачу для desktop, то там уже не так все просто. Ресурсы по отрисовке кнопки с темой оформления могут находиться в dll, и чтобы что-то изменить, надо будет писать обвязку для нее.
Угу, поэтому 20 минут, а не 5.
В любом проекте есть вещи, которые нельзя изменить за 20 минут.
Но приведён пример той, которую можно. Там об этом даже написано.
Почему менеджер не может так себя вести на предыдущем этапе?
Я уже написал, что может и написал почему у него этого не получится. Ну, если вы только не говнокодер, как пытаетесь меня в этом уверить. Если говнокодер, то да.
Более того, в тексте прямо говорится, что менеджер должен так делать всегда.
Для задач на 20 минут — да.
И мой коммент был о том, к чему может привести такое поведение — к хреновому коду во всем проекте.
Нет. Как раз ситуация, когда простейшее очевидное действие требует переписывания половины проекта говорит о том, что быдлокодеры уже привели проект на грань краха и то, что он ещё шевелится, это чудо. Да, я предполагаю, что разработчики — это инженеры, а не недоучившиеся студенты, прочитавшие книжку про похапе. Инженер — проектирует и знает, что цвет кнопок будет меняться и рамочки будут появляться и исчезать, поэтому предусматривает гибкость, говнокодер… ну, говнокодит абсолютно жёсткую систему где часть функциональности прибита гвоздями, а часть смазана соплями. А потом придумывает нелепые отмазки.
Потому что настолько простая задача не должна рушить цивилизацию
Ага, то есть уже не говорится, а подразумевается.
В данном случае это пример простой задачи
С точки зрения менеджера
Угу, поэтому 20 минут, а не 5.
Разговор шел про 20 минут для веба. Хотите сказать, что 5 это для десктопа? Попробуйте в приложении 2gis для Windows цвет кнопки поменять. DLL-ку заинжектить это ж недолго. Скажете, исходники нужны? Ну Firefox скачайте. Сколько у вас один билд займет?
| Почему менеджер не может так себя вести на предыдущем этапе?
Я уже написал, что может и написал почему у него этого не получится. Ну, если вы только не говнокодер, как пытаетесь меня в этом уверить. Если говнокодер, то да.
Этот пассаж я не понял, извините. И не заметил в ваших ответах обоснования, почему не получится. В любой ситуации он может сказать, что программист наговнокодил, раз не может спроектировать архитектуру за 20 минут.
Для задач на 20 минут — да.
Там не указано, что это надо делать для маленьких задач. Более того, там прямо указано обратное — делать это постоянно, независимо от задачи.
Инженер — проектирует и знает, что цвет кнопок будет меняться
Повторю, пожалуй. В тексте нет критериев, в каких случаях менеджеру надо так делать, а в каких нет. Там говорится, что надо так делать постоянно. Поэтому когда на простейшее действие надо переписывать половину проекта — это результат прошлой задачи, когда менеджер дал на проектирование 20 минут. А кнопки тут ни при чем.
Да, я предполагаю, что программист компетентен, и говорю о том, что в этом случае описанная ситуация все равно может случиться, но по вине менеджера.
С точки зрения менеджера
Это пример простой задачи с любой точки зрения.
Разговор шел про 20 минут для веба. Хотите сказать, что 5 это для десктопа?
5 для веби. С учётом ковыряния в носу и уговаривания говнокодера — 20.
Попробуйте в приложении 2gis для Windows цвет кнопки поменять.
Думаю, это делается легко.
Ну Firefox скачайте. Сколько у вас один билд займет?
Это из серии, "а если бы он вёз патроны"? Не, даже в этом случае билдом будет заниматься билд-сервер. В процесс изменений это время даже близко не входит.
Более того, там прямо указано обратное — делать это постоянно, независимо от задачи.
Нет, этого там не указано. Это есть случай так называемого вранья. Указано, что конкретная задача внезапно занимает не неделю, а 20 минут.
Повторю, пожалуй. В тексте нет критериев, в каких случаях менеджеру надо так делать, а в каких нет. Там говорится, что надо так делать постоянно.
Повторю, пожалуй. Нет, там не говорится, что так надо делать постоянно. Там дан пример простейшей задачи, которая занимает не более 20 минут времени, кроме случая патологического говнокодерства.
Поэтому когда на простейшее действие надо переписывать половину проекта — это результат прошлой задачи, когда менеджер дал на проектирование 20 минут.
Нет, это результат говнокодерства. Вы, конечно, можете оправдываться, что говнокодить вас "заставил" менеджер, но это настолько нелепая отмазка, что даже не смешно.
Да, я предполагаю, что программист компетентен, и говорю о том, что в этом случае описанная ситуация все равно может случиться, но по вине менеджера.
Не может. Если программист компетентен, конечно.
Нет, этого там не указано.
Нет, там не говорится, что так надо делать постоянно.
Говорится:
менеджер должен следить за работой разработчика или дизайнера. программистам это только поначалу неприятно. дальше, как ни странно — человек втягивается и выравнивается.
Здесь идет речь не о разовой задаче, а о постоянных действиях. Но если вы считаете наоборот, не буду спорить, дело ваше.
Иными словами, тут нужно обучать обе стороны: инженерам нужно объяснить, что технический долг — это не конец света, и что иногда приходится для нужд бизнеса в него залезать, потому что иначе бизнес загнется, и тут уж никому радостно не будет. А не-инженерам нужно объяснить три вещи: что есть система, элементы в проекте взаимосвязаны, и их желание нарисовать красную рамочку вокруг одной иконки требует на самом деле значительной работы; что существует такая штука, как технический долг; и что залезть в него можно, но потом НЕПРЕМЕННО нужно его погасить.
Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера.
В смысле, стоять за спиной и втыкать в монитор? Или каждые 15 минут требовать подробный отчёт о проделанной работе?
В любом случае, дальше не читал, автор очевидно покусан менеджером.
За человека говорят эмоции, поэтому он редко может себя контролировать, обижается и сыпет возражениями.
Чтобы вырулить такую ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму.
...
А самому продвинуть такого человека в очереди на замену.
Багфикс человека: как фиксить баги, которые мешают работать