Почему у людей не получается взять — и выполнить задачу? Откуда берутся заминки, неправильные оценки и прокрастинация? Почему люди не понимают друг друга, хотя вроде бы не дураки и общаются на одном языке?
Как оказалось, причина у всего этого одна — когнитивные искажения. Вот про них и поговорим.
Когнитивные искажения — баги в психике человека, которые мешают объективно воспринимать реальность. Их много и они водятся в каждом — на странице Википедии в списке когнитивных искажений под 130 пунктов, и 129 вы, скорее всего, обнаружите у себя. К ним относится сила первого впечатления, желание оправдываться и даже причина, почему мы не можем дать адекватную оценку по задаче.
Когнитивные искажения — как вредные привычки. Жить можно, но лучше бы с ними покончить. И тут с вредными привычками даже проще: мы хотя бы знаем, что курить или точить пиццу под покровом ночи — грешновато, и надо бы в один прекрасный день это прекратить. А когнитивные искажения если в лицо не знаешь — то даже не представляешь, с чем бороться. Сам мозг против этого (но об этом ниже).
Так как когнитивные искажения мешают работать, понимать друг друга и, по итогу, выполнять задачи, от них нужно избавляться. Это касается менеджеров, разработчиков, дизайнеров, аналитиков, копирайтеров — всех. В идеальном мире каждый сам отлавливает и фиксит свои искажения, но в реальности, как мы знаем, без тестировщиков (взгляда со стороны) такое редко случается. Так что будьте готовы: если вы не фиксите свой баг — однажды окружающие придут на помощь и заставят вас это сделать. А я расскажу, как именно :) Не буду рассматривать все 130 искажений — пройдусь только по тем, которые были пойманы в нашей студии и которые часто встречаются у работников ИТ-сферы.
Генерализация частных случаев
Генерализация частных случаев — когнитивное искажение, из-за которого человек расширяет поставленную задачу. При этом он даже не осознает, что её можно выполнить проще и быстрее. Чаще всего встречается у программистов и редко фиксится самостоятельно. Чтобы вправить это когнитивное искажение, нужна помощь менеджера. Как минимум один раз ему придётся включить режим варан-менеджмента.
Есть такая байка, что варан кусает жертву, при этом отравляет её. Яд действует не сразу, поэтому после варан ходит за покусанным и ждёт, когда тот сдохнет. И уже тогда съедает.
Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера. В отличие от зверей из дикой природы, они не помирают от этого, но — о чудо! — дело делается, а варан остается голодным :) Кстати, программистам это только поначалу неприятно (ну и неприятна сама идея, что с ними так поступят). Дальше, как ни странно — человек втягивается и выравнивается.
Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.
Это невозможно!
Среди когнитивных искажений можно выделить целую группу тех, которые мешают приступить к выполнению задачи. Они тоже чаще встречаются у программистов и дизайнеров, хотя иногда проскакивают и у менеджеров в ответах на хотелки клиентов. И обычно выражаются категоричным: «Это невозможно!».
У такой реакции несколько причин:
- лень разбираться в новой задаче;
- сработал эффект сопротивления, и человек хочет доказать, что он сам волен решать, что делать, а что нет;
- задача противоречит чувству прекрасного.
Этот баг уже легче отловить самому. Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.
Если вы словили это когнитивное искажение у коллеги — задайте ему тот же вопрос, какой задали бы себе: «Скажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?». И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.
Ну и в будущем, если ситуация повторится, на «Это невозможно!» у вас будет кейс, как человек задачу с таким же диагнозом решил за N минут. Напомните ему этот случай пару раз — и дальше он уже научится сам фиксить этот баг.
Проклятие знания
Проклятие знания — ситуация, когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда, кстати, столько непонятых гениев. Среди менеджеров даже больше, чем среди программистов или дизайнеров. В основном этот багуля встречается у неопытных менеджеров — которым кажется, что сделать ВОТ ТАК было очевидным решением, которое даже проговаривать не обязательно (чего, естественно, и не было сделано и не сформулировано в задаче). А то, что программист/дизайнер/аналитик этого не понял — его косяк. Конечно, такое нужно фиксить.
Проклятие знания устраняется самодрессировкой. Нужно отлавливать своё нелогичное поведение и наступать себе на хвост. Пытаться выстроить конструктивный диалог, даже если очень не хочется. А то всю жизнь можно прожить, думая, что все вокруг глупые, а ты один в пальто стоишь красивый. А на деле окажется, что всё совсем наоборот.
Личное оскорбление
Следующее когнитивное искажение — когда критика результата воспринимается как личное оскорбление тем, чью работу критикуют.
Это искажение часто встречается у личностей творческих. Особенно если они не выспались и в плохом настроении. За человека говорят эмоции, поэтому он редко может себя контролировать, обижается и сыпет возражениями. Чтобы вырулить такую ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму.
- Отделить хорошее и плохое.
- В работе, пусть её и нужно переделать, все равно были какие-то положительные моменты — вспомните их и похвалите коллегу.
- Объясните, в чём ошибка. Возможно, человек не знает, как эту ошибку исправить, и именно поэтому сопротивляется и бунтует.
- Инициируйте повторное обсуждение или брейншторм по уже пройденным вопросам.
- Попросите помощи коллег или выделите дополнительный ресурс — например, время на рисёрч.
- Настаивайте на переделке плохого.
- Закрепите пройденный урок: выясните причину, почему искажение активировалось, и запомните, как вы его пофиксили.
Эффект генерации
Отдаю должное: не все когнитивные искажения — причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит её сам, а не воспринимает извне. Поэтому если вы сомневаетесь, что правильно поняли задачу, или боитесь забыть — просто повторите её вслух.
Нечто похожее есть в авиационных регламентах. Когда диспетчер на земле передает какую-то информацию, пилот в самолете должен всю её повторить. В такой ситуации высока цена ошибки, поэтому повторение необходимо, во-первых, чтобы исключить помехи и другие лажи со связью. Во-вторых, чтобы пилот успел выставить нужные параметры, пока слушает, и просто считал их с приборов, когда отвечает. И, в-третьих, чтобы закрепить полученную информацию эффектом генерации — бонусом.
Поэтому не бойтесь и не стесняйтесь повторять постановки — это реальный рабочий приём, проверенный пилотами.
Слепое пятно
Это как раз то, о чем я упоминал в начале статьи — мозг не хочет замечать свои несовершенства. Поэтому существует слепое пятно в отношении когнитивных искажений. Даже если человек знает о них, то вряд ли согласится, что они влияют на его поведение. А последствия спишет на обстоятельства и на глупость окружающих. И, соответственно, не сделает ничего, чтобы пофиксить свои когнитивные искажения.
Поэтому если вы замечаете, что задачи делаются с сучками и задоринками, и хотите это изменить — попробуйте оценить объективно, может, причина тому — когнитивные искажения? Если вам кажется, что конечно нет — лучше на всякий случай спросите коллег. Слепое пятно не действует в отношении чужих багов :)
Теперь, когда вы знаете про когнитивные искажения, и даже понимаете, в каких именно местах они выпирают и мешают работать, вы сможете с ними бороться. Конечно, будет трудно поначалу, да ещё и слепое пятно будет мешаться. Но со временем оно уменьшится. И тогда и вам, и вашим коллегам станет проще жить и работать — в процессах станет меньше необъяснимых лаж и больше конструктива, мира, дружбы и жвачки.
То, что описано в этой статье — верхушка айсберга когнитивных искажений и аномалий в работе нашего мозга. Если тема вас зацепила и хочется ещё — рекомендую почитать эти книги:
- Оливер Сакс. Человек, который принял жену за шляпу
- Джон О. Купер, Тимоти Э. Херон, Уильям Л. Хьюард. Прикладной анализ поведения (парочку ознакомительных глав можно посмотреть здесь)
- Чалдини Р., Кенрик Д., Нейберг С. Социальная психология. Пойми себя, чтобы понять других
- Чалдини Р. Психология влияния. Убеждай, воздействуй, защищайся
Комментарии (48)
youROCK
13.06.2017 13:16+2Нужно больше
золотаконгнитивных искажений!
Wolfas
13.06.2017 15:25+1Так там ссыль на вики. Другое дело как себя вести… Но думаю лучше нам самим это делать. Один очень хороший препод в МИФИ, говорил нету теории без практики. Постараться найти самим, а потом прочитать. Усвоится лучше
Wolfas
13.06.2017 15:37Кстати тема очень интересная. Сделать эксельку. И в нее скидывать свои наблюдения и решения. Отмечать как это в целом влияет на процесс.
MonkAlex
13.06.2017 13:24+1Первое далеко не факт что правильно описано.
Иногда действительно надо поменять ещё тыщу кнопок на зеленые, потому что они все отображают одно и то же.pluck
13.06.2017 14:39Вообще это решается созданием класса кнопки с нужным цветом и другими параметрами и все кнопки с таким стилем наследуются от него? Так как чаще всего кнопки одного стиля, и достаточно поменять цвет в одном месте.
MurzikFreeman
13.06.2017 15:42Мы не знаем как написан этот проект в примере из комикса и каких усилий на самом деле требует смена цвета на кнопке. Да и не столь это важно. Основной посыл этого примера в том, что разработчик или дизайнер врут, называя сроки, но их можно ускорить, постояв у человека над душой.
yvm
13.06.2017 19:36+1Все так, только вот, работа над действительно важным функционалом (не очевидном для варана) будет сорвана. Сделать «быстро» = нарастить тех-долг (но варану это до лампочки, да?)
Neikist
13.06.2017 20:21Более того, часто таких варанов много, и убыстряя выполнение задачи одного — приходится останавливать выполнение задач других варанов.
MurzikFreeman
14.06.2017 09:33Да и вообще, будет ли работа над этой задачей действительно ускорена? Если программист не соврал, он будет под пристальным присмотром варана точно так же выполнять её в течении отведённого срока + дополнительное время которое ему придётся потратить из-за постоянных «А это зачем? А тут можно без этого? А давай порефакторим в следующий раз?». А если он ошибся в сроках и реально можно быстрее, то под пристальным надзором он скорее будет заниматься ИБД, чем признает свою ошибку. В тоже время, без надзора ему будет значительно проще закончить раньше и сказать что он всё же постарался и смог быстрее. С дизайнером это вообще смешная ситуация, когда нужна «Мона Лиза», быстрее выходит только «Чёрный квадрат».
Мне вообще не понятно, зачем идти на конфликт когда в середине проекта появляются новые, не оговорённые заранее требования. Если о зелёной кнопке не было известно с самого начала, виноват в этом варан. И в 99% случаев, если за ним так же походить и понаблюдать, то очень быстро выяснится что без этой зелёной кнопки можно вообще обойтись.
salabon
14.06.2017 03:50На самом деле более жизненная задача, когда проект собран правильно и все кнопки и правда наследуются от одного класса.
Или как в материале 2 кнопки обычная и акцент.
И тебя просят сделать ещё пару кнопок, совсем другого дизайна, которые ничего не наследуют и совсем не похожи. И их только 2 и 2-х разных страницах.
И начинаются костыли вроде инлайновых стилей и т.п.
Neikist
13.06.2017 14:30+3Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.
— Ура! Я знал что разработка порталов и сверхсветовых двигателей выполнимая задача!
Обычно когда говорят «Это невозможно!» имеют в виду что то вроде:
— Это невозможно с текущим бюджетом!
— Это невозможно в указанные сроки!
— Это действительно невозможно ибо противоречит здравому смыслу и/или физическим законам и/или законодательству и т.д. и т.п.alexkunin
13.06.2017 15:06+4Или «это невозможно потому что в результате получится говнокод с костылем, а мой перфекционизм не позволяет мне такого». Из личного опыта, довольно частая причина. :(
LynXzp
13.06.2017 15:28+1Или «я не вижу простого решения». (Чуть вчера не написал заказчику что это невозможно, но решил погуглить чтобы дать доказательства, понятно что нашел ровно обратное.)
alexkunin
13.06.2017 15:30Согласен, иногда контекст не переключается в голове, или уставший уже — смотришь на задачу и видишь только какие-то умопомрачительные варианты. Махнешь рукой, пойдешь спать, а утром — «тю, вот же оно, в две строки».
Nelin
13.06.2017 17:01С личным перфекционизмом можно бороться. Но беда в том, что большинстве случаев это порождает технический долг, объемы которого определить весьма затруднительно.
alexkunin
13.06.2017 17:06Именно. У меня есть пара проектов, где клиенты буквально считают минуты моего рабочего времени. Я вздыхаю, плюю на все и делаю по минимуму, на костылях. И все жду, когда «рванет» технический долг, и тогда я им напишу «я же вам говорил!». А я и правда им говорил, много раз. :(
Exemption
13.06.2017 22:33Или же «это не возможно, потому что затрагиваемая функциональность уже реализована с костылем, а мой перфекционизм не позволяет мне добавить еще один, а текущие оценки задачи — всё переделать»
dimkss
13.06.2017 15:08+1Странно, что этого когнитивного искажения нет в статье.
— А давай ты на завтра сделаешь перевод на все языки мира, прикрутишь карту, и интеграцию с десятью самыми популярными платежными системами.
Ведь не бывает невыполнимых задач!Armleo
13.06.2017 15:25Дайте мне 400.000$, 200 опытных специалистов — сделаем.Ведь все возможно!
dimkss
13.06.2017 15:34На завтра? Вы монстр!
Хотя за часть этой суммы можно нанять несколько хороших юристов, которые все разъяснят менеджеру с такими задачами, и он сам поймет как ошибался. )vikarti
13.06.2017 16:42Либо надо больше денег
либо надо… одного действительно хорошоего специалиста. Из комикса 'как выучить C++ за 21 день'
Хотя… перевод на все языки? А вам точно нужны ВСЕ языки? 103 языков поддерживаемых Google Translate не хватит? А для первой версии?
Платежные системы популярные где именно? Со своей стороны могу сделать 'тяп-ляп-в-п-продакшн' интеграцию с (например) Interkassa или другим агрегатором а уж они поддерживают много что. Если задержки будут — то по вине самой интеркассы (потребуется их быстро убедить включить нас).
А кстати мы вообще имеем право стороннюю платежную систему цеплять в нашем мобильном приложении?
dimkss
13.06.2017 17:11Нет, ну так мы нашу супер систему не сделаем…
Или уже бывают невыполнимые задачи?
vikarti
13.06.2017 16:34>— Ура! Я знал что разработка порталов и сверхсветовых двигателей выполнимая задача!
Вспоминается один переводной фантастическй рассказ где именно таким способом заставили группу ученых сделать антиграв (показали демонстрацию а потом сказали что ученый погиб).
Да, предоставили ресурсы и поддержку.
А еще — Хайнлайн (Время для звезд) вспоминается — получили возможность передавать информацию мгновенно, немного (канал в байты в секунду и увеличить — никак). Сам по себе способ не особо скажем так ценный хотя можно в особых случаях использовать но смысла нет. В пределах Земли померяли (а там еще были с самим каналом сложности — микрозадержки не замерить) — да — вроде мгновенно.
Использовали эту возможность в другом проекте и померяли на расстоянии в световые годы и когда один из объектов — на околосветовой скорости. Да — мгновенно. Итог вообщем понятный — на Землю все участники эксперимента вернулись раньше срока и существенно быстрее чем думали.
А с зеленой кнопкой пример… а что если — программист знает быстрое решение, правда кривое и оно значит что размер приложения вырастет на 5kb x количество кнопок в приложении (а кнопок — сотни) но… это вполне допустимо потому что у нас приложение (единственное на девайсе) ставится на девайс либо на заводе либо при первоначальной настройке (и девайс все равно кабелем подключен)? Программист просто искал (и не нашел) нормальное универсальное решение а тут можно грязный хак сделать. (правда вот что будет если потом таки выяснится что менеджер№2 внезапно решил что а давайте все же выложимся в Google Play а не только для наших специализированных устройств?)
У меня был случай — я пишу заказчику оценку на пару человеко-лет (и там есть пункты — iOS-версия будет работать только на джейлбрейкнутом устройстве + mobilesubstrate потому что то что заказчик хочет — прямо нарушает п.x.y developer agreement и Public API для того что он хочет — нет а для андроида — как бы вообще не пришлось собирать свою прошивку (со всеми проблемами с зоопарком устройств)) а реально: на android все через public api без рута работало, на iOS же… заказчик прямо сказал что приложение будет ставиться через Enterprise Distribution а про функционал — пользователи в курсе вполне будут и согласны, а технически выяснилось что на той версии iOS что была нужна — задача таки решается, через Private API (пришлось взять в зубы IDA для исследования). (Правда заказчик согласился оплатить исследование на тему 'а как это решать вообще в объеме до N' часов).
michael_vostrikov
13.06.2017 16:24+1Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.
А потом тратить на 20 минут больше на каждую связанную задачу для каждого нового разработчика. Или час. Или день.
И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.
Вот дура, заладила блин, не понимает логичных объяснений. Ладно, сделаю костыль, чтобы хоть как-то работало, сами потом придут когда поймут в чем ошибка. А может и вовсе забудут.
avost
17.06.2017 18:41потом тратить на 20 минут больше на каждую связанную задачу для каждого нового разработчика. Или час. Или день.
Или не тратить вовсе, поскольку, в отличии от этого говнокодера, архитектор был умный и разработал нормальную архитектуру приложения в которой не надо тратить неделю на цвет кнопки, но, говнокодер привык относиться к своему коду, как к сборищу костылей и не видит даже этого :).
michael_vostrikov
17.06.2017 20:49разработал нормальную архитектуру приложения
Так речь же о том, что времени на это нет.
avost
17.06.2017 21:02Речь о прокрастнации вообще-то. А если нормальной архитектуры нет, то имеются костыли говнокодера и говнокодеры же обвиняют менеджера в своём говнокодстве.
michael_vostrikov
17.06.2017 21:15На картинке обсуждается решение задачи, а не безделье работника.
Откуда по-вашему возьмется нормальная архитектура, если менеджер требует решать задачи за 20 минут?avost
17.06.2017 23:13На картинке обсуждается решение задачи, а не безделье работника
А вы текст-то прочитали?
Откуда по-вашему возьмется нормальная архитектура, если менеджер требует решать задачи за 20 минут?
Менеджер требует решить за 20 минут одну конкретную задачу, которая решается за 20 минут, если говнокодер до этого не наговнокодил, а сделал как положено. На "сделать как положено" выделяется не 20 минут.
Nelin
18.06.2017 00:25На «сделать как положено» выделяется не 20 минут.
Так бывает?))avost
18.06.2017 00:49На самом деле, выделяется ровно столько времени, сколько займёт у вас задача. А уж делать её хорошо или говнокодить вам решать. Возможно, на этапе принятия решения, вас будут настойчиво убеждать выбрать второй вариант, но лично я не вижу никакого смысла его выбирать.
michael_vostrikov
18.06.2017 07:34Ну так об этом и текст под картинкой. Менеджер настойчиво убеждает выбрать второй вариант.
michael_vostrikov
18.06.2017 07:32В тексте говорится, что менеджер почему-то считает желание разработчика сделать грамотное решение задачи с продуманной архитектурой прокрастинацией.
Менеджер требует решить за 20 минут одну конкретную задачу, которая решается за 20 минут, если говнокодер до этого не наговнокодил, а сделал как положено.
Откуда известно, что задача решается за 20 минут, если специалист дает оценку в несколько дней?
По описанию ситуации предполагается, что проект имеет приемлемое качество. Значит ни о каком "говнокоде до этого" речь не идет. Программист прямо говорит, что при правильном решении на задачу нужно несколько дней, что за 20 минут будут костыли. Менеджер все равно требует решить задачу за 20 минут. Именно в этот момент появляется говнокод. Который и создает проблемы в будущей поддержке.
А если на момент ситуации говнокод уже был, значит эта ситуация повторялась ранее с другой задачей.
На "сделать как положено" выделяется не 20 минут.
Именно это и собирался сделать программист на картинке. Потому что "делать как положено" надо всегда в любой задаче.
avost
18.06.2017 12:24В тексте говорится, что менеджер почему-то считает желание разработчика сделать грамотное решение задачи с продуманной архитектурой прокрастинацией
В тексте говорится, что говнокодер накодил настолько кривые костыли, что для выполнения простейшей задачи ему требуется совершить героический подвиг.
Откуда известно, что задача решается за 20 минут, если специалист дает оценку в несколько дней?
Потому что задача по изменению цвета кнопки не может решаться несколько дней ни при каких обстоятельствах. А если говнокодер утверждает, то это ему нужна неделя, то ему место на бирже труда в очереди за рисовой похлёбкой. Специалистом он не может считаться ни коим образом.
По описанию ситуации предполагается, что проект имеет приемлемое качество
Йес,! Менеджер предполагает, что проект имеет приемлимое качество. Оказывается, это не так. Оказывается, изменение цвета кнопки может разрушить цивилизацию. Это не приемлимое качество. Это — говнокод в чистом виде.
Именно это и собирался сделать программист на картинке
Это нужно было делать на предыдущем этапе. На этом этапе — гнать дебила в шею с волчьим билетом.
michael_vostrikov
18.06.2017 13:45В тексте говорится, что говнокодер накодил настолько кривые костыли
Где именно? Про качество там вообще ничего не говорится.
Потому что задача по изменению цвета кнопки не может решаться несколько дней ни при каких обстоятельствах.
Изменение цвета это просто пример. Я говорил о подобных ситуациях в целом. Когда программист говорит, что надо времени N, а менеджер говорит, что надо N/100. А вовсе не про кнопки.
Если рассматривать конкретно эту задачу, то программист, который интегрировал бутстрап и пару плагинчиков, в принципе не стал бы говорить, что нужна неделя, а просто добавил бы правило в CSS. Но если рассматривать аналогичную задачу для desktop, то там уже не так все просто. Ресурсы по отрисовке кнопки с темой оформления могут находиться в dll, и чтобы что-то изменить, надо будет писать обвязку для нее.
Менеджер предполагает, что проект имеет приемлимое качество. Оказывается, это не так. Оказывается, изменение цвета кнопки может разрушить цивилизацию.
В любом проекте есть вещи, которые нельзя изменить за 20 минут. Про любую из них можно сказать "Оказывается, изменение %this_thing% может разрушить цивилизацию". Значит ли это, что любой проект плохо написан? Нет.
Это нужно было делать на предыдущем этапе.
Почему менеджер не может так себя вести на предыдущем этапе? Более того, в тексте прямо говорится, что менеджер должен так делать всегда. И мой коммент был о том, к чему может привести такое поведение — к хреновому коду во всем проекте.
менеджер должен следить за работой разработчика или дизайнера. программистам это только поначалу неприятно. дальше, как ни странно — человек втягивается и выравнивается. и в итоге оказывается, что вместо недели задачу можно решить за… или 20 минут.
avost
18.06.2017 20:21Где именно? Про качество там вообще ничего не говорится.
Потому что настолько простая задача не должна рушить цивилизацию. Если рушит, значит в консерватории что-то не то.
Изменение цвета это просто пример. Я говорил о подобных ситуациях в целом.
В данном случае это пример простой задачи, которая при любом раскладе не должна приводить к катастрофе. Если бы стояла цель демонстрации подхода к сложной задачи, то пример был бы другим. Разве это не очевидно?
Но если рассматривать аналогичную задачу для desktop, то там уже не так все просто. Ресурсы по отрисовке кнопки с темой оформления могут находиться в dll, и чтобы что-то изменить, надо будет писать обвязку для нее.
Угу, поэтому 20 минут, а не 5.
В любом проекте есть вещи, которые нельзя изменить за 20 минут.
Но приведён пример той, которую можно. Там об этом даже написано.
Почему менеджер не может так себя вести на предыдущем этапе?
Я уже написал, что может и написал почему у него этого не получится. Ну, если вы только не говнокодер, как пытаетесь меня в этом уверить. Если говнокодер, то да.
Более того, в тексте прямо говорится, что менеджер должен так делать всегда.
Для задач на 20 минут — да.
И мой коммент был о том, к чему может привести такое поведение — к хреновому коду во всем проекте.
Нет. Как раз ситуация, когда простейшее очевидное действие требует переписывания половины проекта говорит о том, что быдлокодеры уже привели проект на грань краха и то, что он ещё шевелится, это чудо. Да, я предполагаю, что разработчики — это инженеры, а не недоучившиеся студенты, прочитавшие книжку про похапе. Инженер — проектирует и знает, что цвет кнопок будет меняться и рамочки будут появляться и исчезать, поэтому предусматривает гибкость, говнокодер… ну, говнокодит абсолютно жёсткую систему где часть функциональности прибита гвоздями, а часть смазана соплями. А потом придумывает нелепые отмазки.
michael_vostrikov
18.06.2017 21:19Потому что настолько простая задача не должна рушить цивилизацию
Ага, то есть уже не говорится, а подразумевается.
В данном случае это пример простой задачи
С точки зрения менеджера
Угу, поэтому 20 минут, а не 5.
Разговор шел про 20 минут для веба. Хотите сказать, что 5 это для десктопа? Попробуйте в приложении 2gis для Windows цвет кнопки поменять. DLL-ку заинжектить это ж недолго. Скажете, исходники нужны? Ну Firefox скачайте. Сколько у вас один билд займет?
| Почему менеджер не может так себя вести на предыдущем этапе?
Я уже написал, что может и написал почему у него этого не получится. Ну, если вы только не говнокодер, как пытаетесь меня в этом уверить. Если говнокодер, то да.Этот пассаж я не понял, извините. И не заметил в ваших ответах обоснования, почему не получится. В любой ситуации он может сказать, что программист наговнокодил, раз не может спроектировать архитектуру за 20 минут.
Для задач на 20 минут — да.
Там не указано, что это надо делать для маленьких задач. Более того, там прямо указано обратное — делать это постоянно, независимо от задачи.
Инженер — проектирует и знает, что цвет кнопок будет меняться
Повторю, пожалуй. В тексте нет критериев, в каких случаях менеджеру надо так делать, а в каких нет. Там говорится, что надо так делать постоянно. Поэтому когда на простейшее действие надо переписывать половину проекта — это результат прошлой задачи, когда менеджер дал на проектирование 20 минут. А кнопки тут ни при чем.
Да, я предполагаю, что программист компетентен, и говорю о том, что в этом случае описанная ситуация все равно может случиться, но по вине менеджера.
avost
19.06.2017 13:51С точки зрения менеджера
Это пример простой задачи с любой точки зрения.
Разговор шел про 20 минут для веба. Хотите сказать, что 5 это для десктопа?
5 для веби. С учётом ковыряния в носу и уговаривания говнокодера — 20.
Попробуйте в приложении 2gis для Windows цвет кнопки поменять.
Думаю, это делается легко.
Ну Firefox скачайте. Сколько у вас один билд займет?
Это из серии, "а если бы он вёз патроны"? Не, даже в этом случае билдом будет заниматься билд-сервер. В процесс изменений это время даже близко не входит.
Более того, там прямо указано обратное — делать это постоянно, независимо от задачи.
Нет, этого там не указано. Это есть случай так называемого вранья. Указано, что конкретная задача внезапно занимает не неделю, а 20 минут.
Повторю, пожалуй. В тексте нет критериев, в каких случаях менеджеру надо так делать, а в каких нет. Там говорится, что надо так делать постоянно.
Повторю, пожалуй. Нет, там не говорится, что так надо делать постоянно. Там дан пример простейшей задачи, которая занимает не более 20 минут времени, кроме случая патологического говнокодерства.
Поэтому когда на простейшее действие надо переписывать половину проекта — это результат прошлой задачи, когда менеджер дал на проектирование 20 минут.
Нет, это результат говнокодерства. Вы, конечно, можете оправдываться, что говнокодить вас "заставил" менеджер, но это настолько нелепая отмазка, что даже не смешно.
Да, я предполагаю, что программист компетентен, и говорю о том, что в этом случае описанная ситуация все равно может случиться, но по вине менеджера.
Не может. Если программист компетентен, конечно.
michael_vostrikov
19.06.2017 13:58Нет, этого там не указано.
Нет, там не говорится, что так надо делать постоянно.Говорится:
менеджер должен следить за работой разработчика или дизайнера. программистам это только поначалу неприятно. дальше, как ни странно — человек втягивается и выравнивается.
Здесь идет речь не о разовой задаче, а о постоянных действиях. Но если вы считаете наоборот, не буду спорить, дело ваше.
hoack
13.06.2017 17:38+2Первый и второй примеры напрямую связаны с характерным когнитивным искажеием у не-инженеров: отсутствием системного видения. Для очень многих не-технических людей система выглядит набором компонентов: Есть кнопки, поля ввода, контрольки, иконки и т.п. При таком взгляде просьба сделать кнопку зеленой, а заголовок заставить менять цвет каждый час выглядят очень невинными, простыми, и искреннее недоумение вызывает сопротивление инженеров. Ну, а инженеры сопротивляются, потому что понимают, что сделать правильно — долго и дорого, а сделать быстренько — значит, написать криво и немедленно залезть в технический долг.
Иными словами, тут нужно обучать обе стороны: инженерам нужно объяснить, что технический долг — это не конец света, и что иногда приходится для нужд бизнеса в него залезать, потому что иначе бизнес загнется, и тут уж никому радостно не будет. А не-инженерам нужно объяснить три вещи: что есть система, элементы в проекте взаимосвязаны, и их желание нарисовать красную рамочку вокруг одной иконки требует на самом деле значительной работы; что существует такая штука, как технический долг; и что залезть в него можно, но потом НЕПРЕМЕННО нужно его погасить.
prefrontalCortex
13.06.2017 20:16Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера.
В смысле, стоять за спиной и втыкать в монитор? Или каждые 15 минут требовать подробный отчёт о проделанной работе?
В любом случае, дальше не читал, автор очевидно покусан менеджером.
NewMan_by
15.06.2017 18:57+1Хотите сказать, что не встречали такое в жизни, то есть когда кого-то заносит со сроками? Да и причин тут может быть куча, от «покусан перфекционистом» до «не хочу думать, как это сделать во вменяемые сроки».
nwalker
14.06.2017 15:38За человека говорят эмоции, поэтому он редко может себя контролировать, обижается и сыпет возражениями.
Чтобы вырулить такую ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму.
...А самому продвинуть такого человека в очереди на замену.
MurzikFreeman
Работать над поиском другой работы.
dgrees
Ну почему же, для начинающих часто полезно, а то их не в ту степь очень легко уводит.