Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 310
Распечатать и повесить на стенку. Отличный пост!
>> Когда я спрашиваю статус твоей задачи, в подавляющем большинстве случаев меня интересует ответ на единственный вопрос: «Когда задача будет завершена?».
Ну так и спрашивайте «когда примерно задача будет завершена?», чтоб не получать ответы «статус „сине-красный“».
>> Тестеры не отвечают за качество ПО
Странные у вас какие-то тестеры… у нас отдел с тестерами называется именно «отдел качества ПО», и именно они по тест-картам, которые составляются по описанию архитектуры и прочим техническим и функциональным тестам, прогоняют всевозможное тестирование: модульное, функциональное, интеграционное… перед тем, как будет принято решение отдавать в продакшн или нет.
>> Никто кроме тебя твой код лучше не знает
Баян, но тестеры мучают программы зачастую лучше, чем разработчик.
Ну так и спрашивайте «когда примерно задача будет завершена?», чтоб не получать ответы «статус „сине-красный“».
>> Тестеры не отвечают за качество ПО
Странные у вас какие-то тестеры… у нас отдел с тестерами называется именно «отдел качества ПО», и именно они по тест-картам, которые составляются по описанию архитектуры и прочим техническим и функциональным тестам, прогоняют всевозможное тестирование: модульное, функциональное, интеграционное… перед тем, как будет принято решение отдавать в продакшн или нет.
>> Никто кроме тебя твой код лучше не знает
Баян, но тестеры мучают программы зачастую лучше, чем разработчик.
1. Вы ни разу не сталкивались с ситуацией, когда на вопрос «Когда задача будет завершена?» вам начинают рассказывать про «интимные подробности твоих непростых взаимоотношений с очередным плагином к jQuery»?
2. Про «Тестеры не отвечают за качество ПО» Вы меня к сожалению не услышали. Можно спросить, а за что у вас разработчики отвечают тогда?
2. Про «Тестеры не отвечают за качество ПО» Вы меня к сожалению не услышали. Можно спросить, а за что у вас разработчики отвечают тогда?
1. Сталкивался, и исходя из своего опыта и опыта разработчика пытаемся вместе перевести это в человеко-часы. Вам ниже ответили про предсказание будущего.
2. За разработку ПО по ТЗ, первичной проверке соответствия ПО этому ТЗ. Формально альфа-тестирование. Тестеры отвечают именно за «можно или нельзя ставить ПО на боевые сервера». Они даже не тестеры, а QA, что подразумевает нечто большее. И еще, баги есть везде, и это нормально, это такой же артефакт разработки как и прочие. И это не вина разработчика, что он промухал баг. Хотя получат по шапке все, но не конкретно разработчик.
2. За разработку ПО по ТЗ, первичной проверке соответствия ПО этому ТЗ. Формально альфа-тестирование. Тестеры отвечают именно за «можно или нельзя ставить ПО на боевые сервера». Они даже не тестеры, а QA, что подразумевает нечто большее. И еще, баги есть везде, и это нормально, это такой же артефакт разработки как и прочие. И это не вина разработчика, что он промухал баг. Хотя получат по шапке все, но не конкретно разработчик.
На мой взгляд разработчик должен реализовать ПО по ТЗ и тестировать то, что сотворил в рамках реализации конкретной задачи.
Если разработчик отдал в отдел качества не проверенную задачу, то почти наверняка она вернется к нему со списком багов. Это так называемая «разработка через ошибки» приводит к:
— срыву сроков разработки
— низкому качеству ПО
— росту команды разработки
Если разработчик отдал в отдел качества не проверенную задачу, то почти наверняка она вернется к нему со списком багов. Это так называемая «разработка через ошибки» приводит к:
— срыву сроков разработки
— низкому качеству ПО
— росту команды разработки
Если разработчик провел проверку и ничего не нашел, но на тестах QA продукт повзрывался, он всё равно вернется и приведет к тому, что вы описали. Но не расстреливать же за это разработчика? Тестирование разработчиком безусловно должно быть, но оно явно не должно быть основополагающим и решающим.
согласен в таком изложении. Хотя поанализировал бы, почему разработчик не нашел ошибки…
Возможно потому, что в какой-то момент его отвлекли от задачи очередным емайлом(звонком/обращением/заданием/вопросом) которое вырвало его из контекста текущей разработки или тестирования.
А еще возможней потому, как мать не может убить своего ребенка — он знает свою систему, и знает, как с ней обращаться, поэтому ему и в голову не придут самые абсурдные юзкейсы, в отличие от человека, которому дан интерфейс, а он даже доку не читал — «все должно быть понятно и интуитивно, и я получу именно то, что хочу, если сделаю так и так». А тараканы в голове у всех разные и самые невероятные.
Как говорил Эйнштейн, бесконечны только вселенная и человеческая глупость. А глупыми мы бываем все, и юзеры и разработчики — хотя бы 5 минут в день.
Как говорил Эйнштейн, бесконечны только вселенная и человеческая глупость. А глупыми мы бываем все, и юзеры и разработчики — хотя бы 5 минут в день.
Это вы исходите из ситуации, что ТЗ существует и оно вменяемое. Иногда на голову сваливается уже утверждённая и подписанная спецификация, в которой катастрофически не хватает детализации. У аутсорсеров такое часто, особенно если субподряд — заказчик с конечным заказчиком чё-то там договорились, а разработчикам потом хоть стреляйся.
Абсолютно с вами согласен. Именно QA отвечают за качество продукта.
Во-первых, если в команде 10-20 программистов, то каждый из них хорошо знает свою область кода, но не код всего продукта.
Во-вторых, у программиста может никогда не быть таких настроек окружения, в которых тестируют тестировщики.
В третьих, что самое главное, даже крутой программист — посредственный тестировщик. И ему в голову не придет использовать продукт таким образом, каким это может сделать хороший QA. Ну, или каждый второй «одаренный» пользователь.
Во-первых, если в команде 10-20 программистов, то каждый из них хорошо знает свою область кода, но не код всего продукта.
Во-вторых, у программиста может никогда не быть таких настроек окружения, в которых тестируют тестировщики.
В третьих, что самое главное, даже крутой программист — посредственный тестировщик. И ему в голову не придет использовать продукт таким образом, каким это может сделать хороший QA. Ну, или каждый второй «одаренный» пользователь.
Именно QA отвечают за качество продукта.
То есть, если
— в среду разработчик Роман отдал код на проверку
— в четверг QA Кузьмич нашёл кучу багов
— в пятницу релиз и ничего не исправлено и не перетестировано,
то за качество продукта отвечает QA? Нет, по уму он в данной ситуации QA даёт информацию о качестве ПО главному на проекте, который должен принять решение о релизе или переносе оного.
Так всё верно. Проджект менеджер читает отчёт специалиста из QA Кузьмича о найденых дефектах и решает, отправлять ли продукт в продакшен. И тут уже возможны четыре ветки событий:
1) Качество ужасное и идти в продакшен нельзя. Тут влетает Роману, поскольку он не смог выпустить продукт в соответствии с ТЗ в разумные сроки.
2) Качество ужасное, но ПМ решает идти в продакшен. Компания терпит убытки из-за найденых дефектов, влетает, в первую очередь, ПМу.
3) Качество среднее, продакшен, но обнаружилось несколько проблем, не отловленных командой Кузьмича. В этом случае виноват QA, поскольку предоставил неверную информацию о качестве продукта.
4) Качество ужасное, ПМ решает идти в продакшен, софтина выстреливает, все счастливы. Роман и Кузьмич едят бесплатные печеньки на кухне, ПМ катается на новом мерсе.
При разборе полётов (первые 3 сценария) ПМ всё равно влетит, но причины разные.
1) Качество ужасное и идти в продакшен нельзя. Тут влетает Роману, поскольку он не смог выпустить продукт в соответствии с ТЗ в разумные сроки.
2) Качество ужасное, но ПМ решает идти в продакшен. Компания терпит убытки из-за найденых дефектов, влетает, в первую очередь, ПМу.
3) Качество среднее, продакшен, но обнаружилось несколько проблем, не отловленных командой Кузьмича. В этом случае виноват QA, поскольку предоставил неверную информацию о качестве продукта.
4) Качество ужасное, ПМ решает идти в продакшен, софтина выстреливает, все счастливы. Роман и Кузьмич едят бесплатные печеньки на кухне, ПМ катается на новом мерсе.
При разборе полётов (первые 3 сценария) ПМ всё равно влетит, но причины разные.
1. Никто не требует от программиста знать код всего проекта, но он должен отвечать за то, что изменил. Если он изменил в одном месте, а в другом из-за этих изменений посыпалось, кто виноват? QA? Кто в первую очередь должен анализировать изменения кода?
2. Если будет в проде найден баг, а разраб скажет, что у него это не воспроизводилось, т.к. среда разработки другая, то что, не чиним баг?
3. Разработчик обязан выполнить юс кейсы из ТЗ по реализуемой задаче на своей среде разработки. Чтобы не было слез умиления или восклицаний типа «Ой...», когда грозный тестировщик поманит пальчиком крутого программиста.
2. Если будет в проде найден баг, а разраб скажет, что у него это не воспроизводилось, т.к. среда разработки другая, то что, не чиним баг?
3. Разработчик обязан выполнить юс кейсы из ТЗ по реализуемой задаче на своей среде разработки. Чтобы не было слез умиления или восклицаний типа «Ой...», когда грозный тестировщик поманит пальчиком крутого программиста.
Здесь нужно разделить модульное/интеграционное тестирование и функциональное.
В первом случае тестирование всецело лежит на программисте, это его зона ответственности.
Во втором — тратить силы разработчика на проверку всех возможных вариантов поведения пользователя нерационально, разработчик должен проверять основные usecase'ы, а для всего остального и предназначен отдел тестирования и QA.
В первом случае тестирование всецело лежит на программисте, это его зона ответственности.
Во втором — тратить силы разработчика на проверку всех возможных вариантов поведения пользователя нерационально, разработчик должен проверять основные usecase'ы, а для всего остального и предназначен отдел тестирования и QA.
Вот это вот «кто виноват» ужасно вредный вопрос и ни к чему хорошему не приводит. У нас стали говорить «не кто виноват, а как сделать так, чтобы это больше не случилось». Такой подход гораздо конструктивней и безопасней
QA отвечает за проверку качества, а не за само качество результата разработки.
QA проверяет «производное качество» — «качество ТЗ» умножено на «качество разработки». Соответствует ли продукт или фича заявленому производному качеству или нет, и на сколько. Когда результат разработки попадает в QA, эго качество подразумевается, а QA проверив выставляет уровень соответствия качеству. Дальше ПМ решает как быть с результатом разработки такого уровня соответствия… внедрять или править.
QA проверяет «производное качество» — «качество ТЗ» умножено на «качество разработки». Соответствует ли продукт или фича заявленому производному качеству или нет, и на сколько. Когда результат разработки попадает в QA, эго качество подразумевается, а QA проверив выставляет уровень соответствия качеству. Дальше ПМ решает как быть с результатом разработки такого уровня соответствия… внедрять или править.
Видать вы работаете на отличных проектах.
У меня на всех проектах тестировщики в мыле, а программисты как раз… нет
(соотношение программистов к тестировщикам везде было 2 к 1)
У меня на всех проектах тестировщики в мыле, а программисты как раз… нет
(соотношение программистов к тестировщикам везде было 2 к 1)
Значит у Вас «программисты» просто не вовлечены в процесс обеспечения качества вашего продукта.
Есть же типовые хорошо известные примеры для решения проблемы «занятости», описанной Вами:
— программисты дополнительно пишут автоматизированные тесты, тогда в «мыле» круглосуточно может быть система «непрерывной интеграции\тестирования»
— тестировщик незабивает на забывает про тест план, тогда программисты могут помочь выполнить ручные тесты, причем четко и формально, т.е. без привнесения своей субъективности разработчика!
А, соотношение «2 разработчика и 1 QA инженер хорошей квалификации» является идеальным для большинства случаев.
Конечно, бывают исключения. Например, этап багфиксинга может потребовать бОльшее количество QA инженеров, которое может значительно превышать количество разработчиков, поправивших маленький-маленький баг в ядре системы перед выпуском.
Есть же типовые хорошо известные примеры для решения проблемы «занятости», описанной Вами:
— программисты дополнительно пишут автоматизированные тесты, тогда в «мыле» круглосуточно может быть система «непрерывной интеграции\тестирования»
— тестировщик не
А, соотношение «2 разработчика и 1 QA инженер хорошей квалификации» является идеальным для большинства случаев.
Конечно, бывают исключения. Например, этап багфиксинга может потребовать бОльшее количество QA инженеров, которое может значительно превышать количество разработчиков, поправивших маленький-маленький баг в ядре системы перед выпуском.
Ну ведь если задача — ерунда, нужно спорить и пытаться это доказать. Задача же менеджера дать понять, что «просто так надо». Часто бывает, что клиент придумал очередную чушь, но не понимает, что это конкретная реальная чушь.
Пункт 100 очень спорный: «Как показывает моя практика 1% может растянуться и на час, и на день, и на неделю.»
Именно. И что вы хотите от программиста? Чтобы он слетал в будущее и рассказал вам, насколько растянется этот один процент?
Работая программистом часто приходится делать вещи, которые никогда еще не делал: прикручивать код, который видешь в первый раз; исправлять багу, которую даже близко не представляешь как пофиксить. Особенно доставляет интеграция со сторонними системами/сервисами/программами.
Вы требуете от программиста предстказывать будущее. Ни больше, ни меньше.
Именно. И что вы хотите от программиста? Чтобы он слетал в будущее и рассказал вам, насколько растянется этот один процент?
Работая программистом часто приходится делать вещи, которые никогда еще не делал: прикручивать код, который видешь в первый раз; исправлять багу, которую даже близко не представляешь как пофиксить. Особенно доставляет интеграция со сторонними системами/сервисами/программами.
Вы требуете от программиста предстказывать будущее. Ни больше, ни меньше.
А что вы тогда хотите от руководства? Чтобы он слетало в будущее и рассказало вам будет ли у вас зарплата в следующем месяце? Работая руководителем часто приходится делать вещи, которые никогда еще не делал: работать с клиентом, которого видешь в первый раз, разбираться с налоговиками даже не представляя как. Особенно доставляют сторонние контрагенты и субподрядчики.
Вы требуете от руководства предсказывать будущее. Ни больше, ни меньше.
Вы требуете от руководства предсказывать будущее. Ни больше, ни меньше.
Эстимейты — не точная наука.
Тут нужно прояснить очень важный момент: вы платите за работу или за конечный результат? Если второй вариант — претензий нет. Если первый — то вы платите за то, что программист не сидит ковыряясь в носу, а решает проблему. Решил он ее к какому-то вашему сроку или нет — это уже к (де~)мотивации. Но формально он сидел и решал проблему. А значит деньги ему полагаются, и ему пофигу на то, что у вас там с налоговиками. Он свою часть трудового договора выполнил.
А еще есть места где платят за работу? У меня бизнес, а не благотворительность.
Представьте себе. И по моему скромному мнению на таких работах, где платят за работу (а такое могут себе позволить либо гос.компании либо крупный бизнес), разработчикам и прочему ИТ-люду, живется лучше, чем в малом бизнесе, где постоянно горят сроки, царит финансовая нестабильность, а разработчики виноваты в срывании сроков, особенно которые ПМ сам проставил ибо пообещал это заказчику без согласования с разработчиками.
Сочувствую Вам
Есть люд, который прется от челленджей и решения задач на пределе своих возможностей,
и есть люд, у которого единственная ценность — «чтоб не трогали» и чтобы встать с рабочего кресла ровно в пять вечера.
Вторых в штуках больше (особенно в гос. и крупных компаниях), но я бы не стал их ценности равнять с ценностями вообще всех представителей отрасли.
и есть люд, у которого единственная ценность — «чтоб не трогали» и чтобы встать с рабочего кресла ровно в пять вечера.
Вторых в штуках больше (особенно в гос. и крупных компаниях), но я бы не стал их ценности равнять с ценностями вообще всех представителей отрасли.
Челленджи и решения задач на пределе возможностей это интересно многим и в гос/крупных компаниях. Поверьте, у нас тоже есть разработчики, которые не бегут в 5 вечера домой, а засиживаются, если они поймали поток и до вечера, и по выходным. Но, ключевой момент, на который я хотел бы обратить ваше внимание — это чувство стабильности, в частности чувство уверенности в том, что определенного числа будет зарплата. И она резко не уменьшится от того, что он 4 ночи решал убойную задачу, но так и не смог ее выполнить в срок. И именно эту уверенность больше дает крупный бизнес, нежели малый (по крайней мере по моему опыту).
Очень часто это чувство стабильности — ложное, разработчиков запросто отправляют на сокращение при кризисе, реорганизации конторы (централизуя разработку в один город и не ваш), смене собственников и т.п.
При этом у очень многих велик соблазн ничего нового не воспринимать и не пытаться, а окопаться на своем десятилетнем говнокоде, который уже сгнил настолько, что его развивать никто не сможет.
Как по мне, так лучшее чувство стабильности дает запас кеша, знание людей в других компаниях и постоянное изучение актуальных технологий, которое позволит выйти на новое место в течении недели-двух.
Я видел людей со «стабильными рабочими местами», которых отправили на помоечку с их большими проектами на дельфи 3 и фокспро. Общаясь с теми кто давно в полиграфической отрасли, я наслышан о множестве тех, кто не осилил перейти с наборных столов на софт для верстки и так же пошел на помоечку (несмотря на работу в крупной и стабильной компании).
При этом у очень многих велик соблазн ничего нового не воспринимать и не пытаться, а окопаться на своем десятилетнем говнокоде, который уже сгнил настолько, что его развивать никто не сможет.
Как по мне, так лучшее чувство стабильности дает запас кеша, знание людей в других компаниях и постоянное изучение актуальных технологий, которое позволит выйти на новое место в течении недели-двух.
Я видел людей со «стабильными рабочими местами», которых отправили на помоечку с их большими проектами на дельфи 3 и фокспро. Общаясь с теми кто давно в полиграфической отрасли, я наслышан о множестве тех, кто не осилил перейти с наборных столов на софт для верстки и так же пошел на помоечку (несмотря на работу в крупной и стабильной компании).
Вы правы в том, что даже работа в крупной компании не гарантирует трудоустройства, но там в этом смысле всё честно: либо ваши услуги нужны и у вас их покупают по оговоренной цене, либо они не нужны и вы оказываетесь на улице.
На самом же деле вопрос — он не в чувстве стабильности, а в подходе. Либо мы вместе — одна команда и при промахе все сидим на хлебе и воде, а при удаче — ездим на мерседесах, либо я — наёмный рабочий, делающий заранее оговоренную работу за заранее оговоренную плату. Первый вариант — это стартап, второй — большая контора. Каждый выбирает то, что ему нравится.
«Русский бузинесс» же, зачастую, устроен так, что когда контора «на коне», то её учредители и инвесторы «катаются в шоколаде», а наёмные рабочие получают оговоренную зарплату, а когда бизнес «проседает», то вдруг начинаются разговоры про то, что в кассе мало денег и зарплата вдруг урезается вдвое или не выплачивается. Да какая мне нафиг разница? Если прибыли мне не принадлежат, то и убытки — тоже не моя проблема.
На самом же деле вопрос — он не в чувстве стабильности, а в подходе. Либо мы вместе — одна команда и при промахе все сидим на хлебе и воде, а при удаче — ездим на мерседесах, либо я — наёмный рабочий, делающий заранее оговоренную работу за заранее оговоренную плату. Первый вариант — это стартап, второй — большая контора. Каждый выбирает то, что ему нравится.
«Русский бузинесс» же, зачастую, устроен так, что когда контора «на коне», то её учредители и инвесторы «катаются в шоколаде», а наёмные рабочие получают оговоренную зарплату, а когда бизнес «проседает», то вдруг начинаются разговоры про то, что в кассе мало денег и зарплата вдруг урезается вдвое или не выплачивается. Да какая мне нафиг разница? Если прибыли мне не принадлежат, то и убытки — тоже не моя проблема.
Но, ключевой момент, на который я хотел бы обратить ваше внимание — это чувство стабильности
Далеко не для всех людей этот вопрос является ключевым. Тем более стабильность==отсутствие риска, а без рисков не бывает крупных выигрышей.
Если вам понравится такое сравнение, то программисты — это как футболисты. Футболист выходит на поле и старается сделать всё для победы своей команды, но случаются и поражения. Однако платить футболисту приходится независимо от результата, потому что поражения неизбежны. Не могут же всегда все побеждать, кому-то приходится и проигрывать. Да, за особо крутую победу можно и наградить сверх нормы, но недоплатить нельзя. Это не благотворительность, а особенность бизнеса, в котором стопроцентный результат невозможен по определению.
Если вам не нравятся конкретные футболисты, можно их уволить и взять других, получше, но на тех же условиях. То есть если не хотите заниматься благотворительностью, надо держать хороших специалистов, вот и всё.
P.S. А я люблю слово «программист». Оно у меня ассоциируется не с девяностыми, а с рассказами Лема и Азимова. Программист — это звучит гордо, это там же, где космонавт и физик-ядерщик. Неужели какие-то бабушки или бухгалтеры так круты, чтобы перебить большую литературу?
Если вам не нравятся конкретные футболисты, можно их уволить и взять других, получше, но на тех же условиях. То есть если не хотите заниматься благотворительностью, надо держать хороших специалистов, вот и всё.
P.S. А я люблю слово «программист». Оно у меня ассоциируется не с девяностыми, а с рассказами Лема и Азимова. Программист — это звучит гордо, это там же, где космонавт и физик-ядерщик. Неужели какие-то бабушки или бухгалтеры так круты, чтобы перебить большую литературу?
Проблема в том, что бизнес у вас, а не у ваших сотрудников. Для них это таки работа. И если они выполняют свою работу, а у вас ничего не клеится, то это будут ваши личные проблемы, а не сотрудников
Вы не поверите, но во множестве мест платят, даже не за работа, а за то что ты приходишь и сидишь на работе.
Есть 20 рабочих дней в месяце, вот ты должен отсидеть все 20 дней.
Как пример 2 варианта:
1) Программист приходит на работу и 4 часа работает, а вторые 4 часа отдыхает (делает вид что работает или самообучается) и так все 20 дней
2) Программист приходит на работу и работает все 8 часов, но только 10 дней, а остальные 10 дней просто не ходит на работу. (самообучается дома)
Кем будет доволен начальник?
(В моей практике довольны будут 1, а 2 уволят )
Есть 20 рабочих дней в месяце, вот ты должен отсидеть все 20 дней.
Как пример 2 варианта:
1) Программист приходит на работу и 4 часа работает, а вторые 4 часа отдыхает (делает вид что работает или самообучается) и так все 20 дней
2) Программист приходит на работу и работает все 8 часов, но только 10 дней, а остальные 10 дней просто не ходит на работу. (самообучается дома)
Кем будет доволен начальник?
(В моей практике довольны будут 1, а 2 уволят )
Программист — это как ученый-экспериментатор. Для поиска хорошего решения может понадобиться один эксперимент, а может и пятьдесят. Эдиссон, вон, больше 1000 эксперименов провел, пока лампочку изобретал.
Как то вы совсем немного преувеличиваете, чуть менее, чем полностью.
Программирование в 95% проектов — это рутина от начала и до конца. Это давно уже из элитарного искусства превратилось ремесло.
Программирование в 95% проектов — это рутина от начала и до конца. Это давно уже из элитарного искусства превратилось ремесло.
Если бы это было так, написание программ было бы строго предсказуемым, как выпечка тортов. Почему пекарь может закончить известный объём работ в назначенное время, а программисты нет? Если программисты такие лентяи, выгоните их, возьмите ответственных пекарей, научите ремеслу и пусть работают предсказуемо и без срывов сроков.
И не будет этого 1%, который неизвестно когда будет готов.
И не будет этого 1%, который неизвестно когда будет готов.
Я не понимаю, где это я назвал программистов лентяями! Хотя да, хороший программист должен быть в меру ленивым, но у этого образа совсем не негативный образ!
Уровень задач, которые ставятся перед современными программистами сегодня, требует в 95% случаев знания стандартных решений. Так же от программистов требуется знания инструментария и фреймворков, которыми он пользуется.
Что же происходит в абсолютном большинстве случаев? Мракобесие! Программизды творят что то новое, особенное, за что потом самим будет стыдно. Или берут не проверенные инструменты.
На двух последних проектах, которые должны быть сделаны за 3 и 4 месяца соответственно, был один и тот же диалог:
— Чет все надоело…
— А давайте попробуем новый фреймворк?!
— А давайте!
Первый проект закончили за 10 мес и заказчик соскочил. Второй — 7 месяцев. Ну и кто виноват?
И да, лажают не только программисты. Лажают и ПМ, и аналитики.
И кстати, посмотрите «Адскую кухню» и вы поймете, что повар тоже не всегда может сказать точно, когда будет сделана работа.
Уровень задач, которые ставятся перед современными программистами сегодня, требует в 95% случаев знания стандартных решений. Так же от программистов требуется знания инструментария и фреймворков, которыми он пользуется.
Что же происходит в абсолютном большинстве случаев? Мракобесие! Программизды творят что то новое, особенное, за что потом самим будет стыдно. Или берут не проверенные инструменты.
На двух последних проектах, которые должны быть сделаны за 3 и 4 месяца соответственно, был один и тот же диалог:
— Чет все надоело…
— А давайте попробуем новый фреймворк?!
— А давайте!
Первый проект закончили за 10 мес и заказчик соскочил. Второй — 7 месяцев. Ну и кто виноват?
И да, лажают не только программисты. Лажают и ПМ, и аналитики.
И кстати, посмотрите «Адскую кухню» и вы поймете, что повар тоже не всегда может сказать точно, когда будет сделана работа.
И такие программисты есть, которые не любят изучать новое, приходится их заставлять. Я и предлагаю — чтобы избежать проблем, берите нетворческих людей, таких тоже много. Зачем вы ищете экспериментаторов ))
Минусуют как раз творческие люди.
Если вы мне объясните, что творческого в том, чтобы изучить то, что сделали другие, я наверное пойму. Пока не понимаю.
Если вы мне объясните, что творческого в том, чтобы изучить то, что сделали другие, я наверное пойму. Пока не понимаю.
Чтобы изучить фреймворк — ничего творческого. Но который раз я пытаюсь донести мысль, а вы всё в сторону уходите. Ну есть же программисты, профессионалы, которым работа не интересна. Которые работают от забора до обеда. Которые не любят изобретать велосипеды. Нет в документации по фреймворку такой фичи — до свидания, это сделать невозможно. Напишут в поддержку, чтобы фичу под них запилили и будут ждать.
Вы так хотите работать с такими программистами. Вот мне интересно, что у вас с ними получится.
Вы так хотите работать с такими программистами. Вот мне интересно, что у вас с ними получится.
Да вроде я вас хорошо понимаю)
Многих 35+ летних программистов вы выдели, у которых глаза горят при решении каждой задачи? Я очень редко. Почему? На мой взгляд потому, что они уже перепробовали 1000 и 1 фреймворк/язык и понимают, что в их жизни ну нет творчества.Они зачастую работают с 9 до 18. И просто выполняют свою работу. Или подаются в начальники. Или уходят из профессии. И да, это печально.
Я знаю, что в twitter, google, jetbrains and etc все иначе. Но есть также ваяние бизнес фич/отчетов/поддержка бухгалтерии и т.д., где места для творчества почти нет.
А теперь посчитайте, сколько рабочих мест создают первые и сколько вторые. По моим подсчетам хорошо, если 1 к 20.
Моя мысль не в том, что творчества в программировании нет.
Многих 35+ летних программистов вы выдели, у которых глаза горят при решении каждой задачи? Я очень редко. Почему? На мой взгляд потому, что они уже перепробовали 1000 и 1 фреймворк/язык и понимают, что в их жизни ну нет творчества.Они зачастую работают с 9 до 18. И просто выполняют свою работу. Или подаются в начальники. Или уходят из профессии. И да, это печально.
Я знаю, что в twitter, google, jetbrains and etc все иначе. Но есть также ваяние бизнес фич/отчетов/поддержка бухгалтерии и т.д., где места для творчества почти нет.
А теперь посчитайте, сколько рабочих мест создают первые и сколько вторые. По моим подсчетам хорошо, если 1 к 20.
Моя мысль не в том, что творчества в программировании нет.
>>>Но есть также ваяние бизнес фич/отчетов/поддержка бухгалтерии и т.д., где места для творчества почти нет.
Там есть некоторое место для творчества, если человек думает о том как он работает, а не тупо переводит с человеческого языка на машинный. Конечно там творчества маленькое, не мирового масштаба, но оно есть. Представьте себе некоторый спектр: пусть абсолютное отсутствие творчества, это рабочий на конвеере завинчивающий гайку, причем, не думая о работе вообще, а чистое творчество — ученый придумывающий единую теорию всего 100% времени. Мне кажется любой программист где-то между этими точками, только от рода его работы и подхода к ней зависит, где именно.
Там есть некоторое место для творчества, если человек думает о том как он работает, а не тупо переводит с человеческого языка на машинный. Конечно там творчества маленькое, не мирового масштаба, но оно есть. Представьте себе некоторый спектр: пусть абсолютное отсутствие творчества, это рабочий на конвеере завинчивающий гайку, причем, не думая о работе вообще, а чистое творчество — ученый придумывающий единую теорию всего 100% времени. Мне кажется любой программист где-то между этими точками, только от рода его работы и подхода к ней зависит, где именно.
Если к вам на собеседование приходит человек, который не может рассказать, как работает ArrayList, и вы его таки возьмете на работу, он вам творчески создаст продукт из хромированных костылей.
Если вы мне объясните, что творческого в том, чтобы изучить то, что сделали другие, я наверное пойму. У абсолютного большинства программистов время сейчас уходит на изучение в основном на изучение чужого.
Если вы мне объясните, что творческого в том, чтобы изучить то, что сделали другие, я наверное пойму. У абсолютного большинства программистов время сейчас уходит на изучение в основном на изучение чужого.
Если по себе судить, в одно время я переизобрёл контейнеры STL. Да, не осилил документацию и мне казалось, что я сделаю лучше. В итоге после мучений со своими костылями я сейчас с удовольствием пользуюсь STL и понимаю, почему там сделано так, а не иначе. Знаю несколько нюансов, которых нет в документации.
Хотя я изобретал их в своём личном проекте, но вероятно сделал бы тоже самое в рабочем, если бы в то время была потребность. С точки зрения работодателя наверное это ужасно, но без этого я бы просто не смог вырасти.
Хотя я изобретал их в своём личном проекте, но вероятно сделал бы тоже самое в рабочем, если бы в то время была потребность. С точки зрения работодателя наверное это ужасно, но без этого я бы просто не смог вырасти.
я же не против — изобретайте, творите, улучшайте. Но сначала изучите то, что уже есть. Это первая заповедь инженера.
О как!
Предположим, я хочу пройти курс по машинному зрению (теории категорий, etc, не важно). Но мы ведь взрослые люди и понимаем, что почитав книжку пол-выходного, я ничего толком не изучу. Ну никак, чудес не бывает. Надо серьёзно поработать хотя бы часов 200 на этой теме. А где взять столько времени? Отсюда и «А давайте попробуем новый фреймворк...»
Предположим, я хочу пройти курс по машинному зрению (теории категорий, etc, не важно). Но мы ведь взрослые люди и понимаем, что почитав книжку пол-выходного, я ничего толком не изучу. Ну никак, чудес не бывает. Надо серьёзно поработать хотя бы часов 200 на этой теме. А где взять столько времени? Отсюда и «А давайте попробуем новый фреймворк...»
А в чем противоречие? Если вы начали исследование новой для вас области знаний с книги, значит вы не будете изобретать велосипед по незнанию. Т.е. поступите как хороший инженер. Или ученый, если вам это сравнение больше нравится.
Просто я за целесообразность в поступках.
Например, если программист говорит «чойта я устал от spring mvc, давайте попробуем play», то где тут здравый смысл?
Или другой, весьма самовлюбленный и вместе с тем средний программист, натолкнувшись на свое неумение работать с hibernate, перескакивает на eclipselink. И там совершает другие ошибки, которые выплывают уже на проде. Где тут целесообразность в использовании нового фреймворка?
Целесообразно знать свой инструментарий и область знаний, в которой вы работаете. Целесообразно развивать свои мозги, например изучая новые языки/фреймворки/области знаний… Но нецелесообразно использовать инструментарий, который вы изучаете в процессе создания нового проекта потому, что вы устали или вам кто то разрекламировал что то. А вот если вы выбираете новый фреймворк на новом проекте, потому что там уже есть половина того, что вам нужно, то это целесообразно.
Творите, все только выиграют от этого. Но опирайтесь в своем творчестве на знания других, а не на свое незнание.
Просто я за целесообразность в поступках.
Например, если программист говорит «чойта я устал от spring mvc, давайте попробуем play», то где тут здравый смысл?
Или другой, весьма самовлюбленный и вместе с тем средний программист, натолкнувшись на свое неумение работать с hibernate, перескакивает на eclipselink. И там совершает другие ошибки, которые выплывают уже на проде. Где тут целесообразность в использовании нового фреймворка?
Целесообразно знать свой инструментарий и область знаний, в которой вы работаете. Целесообразно развивать свои мозги, например изучая новые языки/фреймворки/области знаний… Но нецелесообразно использовать инструментарий, который вы изучаете в процессе создания нового проекта потому, что вы устали или вам кто то разрекламировал что то. А вот если вы выбираете новый фреймворк на новом проекте, потому что там уже есть половина того, что вам нужно, то это целесообразно.
Творите, все только выиграют от этого. Но опирайтесь в своем творчестве на знания других, а не на свое незнание.
Программирование больше похоже на составление рецепта, чем на выпекание по готовому
Отличное сравнение)
А теперь посчитайте, сколько ресторанов хотя бы с одной звездой Мишлен и сколько заведений, не имеющих их. Что творческого в том, чтобы приготовить картошку по деревенски?
А теперь посчитайте, сколько ресторанов хотя бы с одной звездой Мишлен и сколько заведений, не имеющих их. Что творческого в том, чтобы приготовить картошку по деревенски?
Если бы вы отвечали на мой коммент, вы бы написали «создать новый рецепт картошки по-деревенски»
я все правильно ответил, но давайте отвечу более полно: рецепт нового блюда придумывают доли процента, а готовят по готовому рецепту все остальные.
Для первых это может быть творчеством(если было сотворено реально что то хотя бы чуточку уникально и не является откровенным г.), а для всех остальных — рутина.
Для первых это может быть творчеством(если было сотворено реально что то хотя бы чуточку уникально и не является откровенным г.), а для всех остальных — рутина.
В программировании то же самое, только готовое блюдо по рецепту делает робот. Иногда его называют компилятор. Если привлекают человека, значит блюдо по существующему рецепту не подходит иначе бы его просто скопировали
В-общем, примерно такая же аналогия уже много лет используется в рассуждениях о ПО, например у Мартина нашего Фаулера — попробуйте почитать там.
А вот тут повеселее
Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.
А вот тут повеселее
Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.
Вы знаете, в моей жизни было 3 случая, когда программист называл срок (2-5 дней), в назначенный день назывался новый срок. И так 2-3 месяца. В 2-х первых случаях проекты закрылись и люди не получили всех денег, на которые рассчитывали.
А ведь люди работали, решали задачи. А выхлопа не было. И по барабану им было на бизнес. Но пострадал и бизнес и люди.
А ведь люди работали, решали задачи. А выхлопа не было. И по барабану им было на бизнес. Но пострадал и бизнес и люди.
Программисты от руководства ничего не хотят. Хотя нет, они хотят ТЗ, которое известно до разработки продукта и не поменяется до его конца. Но очень часто приходится работать не по ТЗ, а по ХЗ.
Ну нету у менеджера хорошего расписанного ТЗ до начала проекта. Оно устаканится, когда устаканится. А у программиста нету знания сроков завершения его задач. Когда они завершатся, тогда завершатся.
Ну нету у менеджера хорошего расписанного ТЗ до начала проекта. Оно устаканится, когда устаканится. А у программиста нету знания сроков завершения его задач. Когда они завершатся, тогда завершатся.
Работая программистом тоже весьма часто приходится делать вещи, которые никто никогда еще не делал.
Со многими вашими утверждениями я согласен, но в целом складывается ощущение, что вы стараетесь избежать ответственности. Вам, как руководителю дана власть казнить и миловать, назначать людей и назначать сроки. В первую очередь от ваших решений зависит проект.
+ 001. А у меня на компе работает
Согласен, я готов был плюнуть в лицо тому разработчику, который так ответил на подробное сообщение о баге. Это может быть оправданием тому, что баг попал в продукт, но не может быть оправданием отказу исправлять этот баг.
— 010. Какой мудакпользователь так (с)делает?
Решение о предполагаемом поведение пользователя должно содержаться в требованиях к задаче. Если вы оставили это решение исполнителю, не удивляйтесь результатам.
+ 011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
Задача исполнителя качественно выполнять поставленную задачу. Если он допустил ошибку — это его вина. За свой код нужно отвечать самому, тестирование — всего лишь контроль.
? 100. Какой идиот это писал?
Я, как разработчик, имею право выражать своё мнение по поводу умственных способностей других разработчиков. Не относитесь к этому слишком серьёзно :)
— 101. Готово на 99%
Планировать — это задача руководителя. Спихивать её на исполнителя — это очень некрасиво. Оценить сколько времени замёт отдельная задача очень сложно, но когда у вас есть 100 задач, то тут вам на помощь приходит статистика и распределение вероятностей и точность существенно увеличивается. Исполнитель может помочь вам разделив задачи на несколько категорий, например «совсем простые», «понятно как делать», «что-то сложное и непонятное», и статистика по таким группам будет на много точнее. А требовать конкретный срок выполнения в часах, а потом требовать точного соблюдения этого срока — это порочная практика, которая не даст точности и будет держать исполнителей в постоянном стрессе.
Главная задача исполнителя — сделать хорошо и как можно скорее поставленную задачу. Если он выполняет это, но вы не успеваете сдать проект или продукт не нравится пользователям, то это проблема руководителя.
— 110. Это невозможно!
Если воспринимать дословно, то это безусловно ложь. Но чаще всего разработчик имеет ввиду, что «это делать сложно, а пользы немного». Например выбранный фреймворк этого сделать не может, и придётся сильно его допиливать. Постарайтесь в этом случае выяснить на сколько сложно это будет сделать, самостоятельно оценить выгоду от задания и принять решение, стоит ли оно того.
+ 111. Я такую ерунду делать не буду.
Это не ответ истинного джедая, такой ответ конечно принимать нельзя. Возможно разработчик не понимает важности данной задачи. Постарайтесь объяснить ему, какой профит принесёт проекту эта задача, тогда её выполнение принесёт удовольствие разработчику и он с радостью её сделает.
Ну вот, а хотел написать короткий ответ по конкретному вопросу :)
+ 001. А у меня на компе работает
Согласен, я готов был плюнуть в лицо тому разработчику, который так ответил на подробное сообщение о баге. Это может быть оправданием тому, что баг попал в продукт, но не может быть оправданием отказу исправлять этот баг.
— 010. Какой мудакпользователь так (с)делает?
Решение о предполагаемом поведение пользователя должно содержаться в требованиях к задаче. Если вы оставили это решение исполнителю, не удивляйтесь результатам.
+ 011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
Задача исполнителя качественно выполнять поставленную задачу. Если он допустил ошибку — это его вина. За свой код нужно отвечать самому, тестирование — всего лишь контроль.
? 100. Какой идиот это писал?
Я, как разработчик, имею право выражать своё мнение по поводу умственных способностей других разработчиков. Не относитесь к этому слишком серьёзно :)
— 101. Готово на 99%
Планировать — это задача руководителя. Спихивать её на исполнителя — это очень некрасиво. Оценить сколько времени замёт отдельная задача очень сложно, но когда у вас есть 100 задач, то тут вам на помощь приходит статистика и распределение вероятностей и точность существенно увеличивается. Исполнитель может помочь вам разделив задачи на несколько категорий, например «совсем простые», «понятно как делать», «что-то сложное и непонятное», и статистика по таким группам будет на много точнее. А требовать конкретный срок выполнения в часах, а потом требовать точного соблюдения этого срока — это порочная практика, которая не даст точности и будет держать исполнителей в постоянном стрессе.
Главная задача исполнителя — сделать хорошо и как можно скорее поставленную задачу. Если он выполняет это, но вы не успеваете сдать проект или продукт не нравится пользователям, то это проблема руководителя.
— 110. Это невозможно!
Если воспринимать дословно, то это безусловно ложь. Но чаще всего разработчик имеет ввиду, что «это делать сложно, а пользы немного». Например выбранный фреймворк этого сделать не может, и придётся сильно его допиливать. Постарайтесь в этом случае выяснить на сколько сложно это будет сделать, самостоятельно оценить выгоду от задания и принять решение, стоит ли оно того.
+ 111. Я такую ерунду делать не буду.
Это не ответ истинного джедая, такой ответ конечно принимать нельзя. Возможно разработчик не понимает важности данной задачи. Постарайтесь объяснить ему, какой профит принесёт проекту эта задача, тогда её выполнение принесёт удовольствие разработчику и он с радостью её сделает.
Ну вот, а хотел написать короткий ответ по конкретному вопросу :)
Постарайтесь объяснить ему, какой профит принесёт проекту эта задача, тогда её выполнение принесёт удовольствие разработчику и он с радостью её сделает.
Только если он этот профит проекта примет как личный профит. Грубо говоря, если задача увеличит доход на 10%, а программист не получит даже разовой премии, то…
тестеры не отвечают за качество ПО
Позволю себе не согласиться. В нынешние времена понятие/профессия «тестер» все больше упраздняется, на замену этому давно пришел QA (Quality Assurance), который как раз таки отвечает за качество ПО. И на этапе проектирования, и на этапе разработки, и на этапе отправки в продакшн и после оной.
И, простите уж меня, зануду, но
Цитата из книги Джеймса Баха Lessons Learned in Software Testing:
It’s all too easy to think of yourself as the guardian of quality. But you [QA] don’t create quality, and you don’t take it away. [...] Quality comes from the people who build the product, and that is sometimes a heavy burden for them to bear.
It’s all too easy to think of yourself as the guardian of quality. But you [QA] don’t create quality, and you don’t take it away. [...] Quality comes from the people who build the product, and that is sometimes a heavy burden for them to bear.
Это не отрицает того факта, что QA гарантирует ее (кволити) конечному пользователю. Соответственно является ответственным за то, что гарантирует.
А каким образом QA, который не написал ни строчки кода, может гарантировать качество этого самого кода? Он может только констатировать его качество. Иначе у вас получается, что во всех сырых продуктах виноват QA отдел.
QA гарантирует качество продукта, а не кода. Для гарантии качества кода существует код-ревью. Насчет того, кто виноват — так виноваты по итогу все — и разработчик, и куа, и менеджер. А вообще, как выше уже упоминалось, во многих компаниях, тестировщики/куа как таковые отсутствуют. Есть SDET'ы (например, в Мелкософт), которые как бы и тестированием занимаются, но в разрезе всяческих аджайл-практик (TDD, BDD, ATDD). Кстати, этот подход мне более всего импонирует, т.к. и в QC, и в QA как в отдельной единице команды я все меньше вижу смысла в последнее время
Многие вещи понимаешь только тогда, когда переходишь на другую сторону силы. Когда ты являешься разработчиком, всё это работает почти на уровне рефлексов :)) Подсознательное желание не тратить время на глупые (с твоей точки зрения) вещи.
На мой взгляд, слишком категорично.
Пункты справедливы пока ты простой программист.
Но большинство пунктов вполне допустимы, как только перерастаешь этот этап.
Практический любой пункт имеет право на жизнь, если добавить после фразы обоснование.
Пункты справедливы пока ты простой программист.
Но большинство пунктов вполне допустимы, как только перерастаешь этот этап.
Практический любой пункт имеет право на жизнь, если добавить после фразы обоснование.
001. А у меня на компе работает
Как правило, такое начинают говорить в ответ на N-цатое к ряду сообщение от QA/пользователя, состоящее из слов «у меня не работает». Причем, как показывает практика, в половине случаев проблема в рука/голове QA/пользователя. Так что это такая тактичная вариация на тему: «Отвали или скажи человеческим языком, что не так».
010. Какой мудакпользователь так (с)делает?
По ситуации. Иногда кто-то гордо отстреливает себе ногу, жамкая не глядя на «OK» в messagebox'ах с восклицательными знаками, а потом начинает вопить: «Усе пропало!11». Мудаков по ту сторону хватает, а удовлетворение мудаков не входит в должностные обязанности разработчика — за этим в саппорт.
011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
Опять-таки ситуационно-справедливое утверждение: если фатальные проблеы возникли в экзотических конфигурациях, а разработчик проверил на одной-двух общеупотребительных, кто тут виноват? И поправьте меня, но время разработчика стоит дороже времени QA, так что тщательное и всестороннее тестирование программистом идет в убыток компании.
100. Какой идиот это писал?
Вполне нормальная рабочая фраза. Имеет лютый профилактическо-воспитательный эффект, если была высказана громко и вслух, чтобы каждое заинтересованное лицо услышало. Воспитательный эффект усиливается еще сильнее, если в конце-концов идиотом оказался автор реплики.
101. Готово на 99%
Проблема заключается в том, что вопрошающий, как правило, страдает от крайней степени безделия. И реалистичная оценка «через пару дней» вызовет массу вопросов: «А почему так долго? Да это же как два байт переслать! Да я на школьной олимпиаде такое за 20 минут кодил...» — начиная с какого-то момента становится проще «кормить завтраками», чем проводить разъяснительную работу с человеком, которого «интимные детали не интересуют».
110. Это невозможно!
Никогда не приходило в голову, что невозможно то, что ты сказал, а в более конкретной формулировке проблема как раз таки разрешима? В любом случае, есть мнение, что разработчик разбирается в возможно/невозможно куда лучше, чем тимлид, которому важно только «через сколько часов будет готово».
111. Я такую ерунду делать не буду.
Это политкорректный вариант: «Ты меня вусмерть достал, сейчас напишу заявление и ищи других идиотов, которым будешь парить мозг».
Если в твоей команде часто всплывают озвученные высказывания, это повод призадуматься над вопросом: «Толи лыжы не едут, толи я какой-то-не-настолько-грамотный-руководитель».
Ужас какой у Вас в голове…
Прямо таки с языка сняли:)
Отличное дополнение исключениями к правилам в самой статье.
Отличное дополнение исключениями к правилам в самой статье.
Только Гамма не Эрик, а Эрих (Erich).
В трех битах 8 значений, отсутствие антипатерна 000 режет глаз, очевидно, автор не программист и не developer.
Вот оно, подросло новое поколение КЭПов. Вырвалось из своих школьных застенков и несет в мир неоспоримые ценности.
Спасибо юный КЭП.
И да, кстати, ты более не достоин звания ШКОЛОТА, и теперь мы все видем как ты встал на тропу взросления. Да, еще остались словечки вроде «Чувак», и злотворное влияние «Камеди Клаба» в виде мата в заголовках, но ничего, Хабрахабр выкует из тебя настоящего человека, правильным путем идете товарисч.
Ждем от вас статей из серии, == сравнивает значения а = присваивает и это не одно и тоже, и бесцелера, единица не ноль, чувак, усвой это раз и навсегда!!!
Спасибо юный КЭП.
И да, кстати, ты более не достоин звания ШКОЛОТА, и теперь мы все видем как ты встал на тропу взросления. Да, еще остались словечки вроде «Чувак», и злотворное влияние «Камеди Клаба» в виде мата в заголовках, но ничего, Хабрахабр выкует из тебя настоящего человека, правильным путем идете товарисч.
Ждем от вас статей из серии, == сравнивает значения а = присваивает и это не одно и тоже, и бесцелера, единица не ноль, чувак, усвой это раз и навсегда!!!
может и не выкует настоящего человека — у него больше сотни раз менялся рейтинг, а в итоге всего +6 — кажется мне, что заминусуют его раньше
> и теперь мы все видем как ты встал на тропу взросления
Тоже мне, папаша. Умные (али как тебе удобно «взрослые») люди себя так не ведут. Да и пишут пограмотнее.
> злотворное влияние «Камеди Клаба» в виде мата в заголовках
Ну и сидите на своих «аншлагах» да «бенни хилсах». В «Камеди», а так же его ответвлениях, есть много интеллектуального юмора, откинув ширпотреб из пошлости.
> Хабрахабр выкует из тебя настоящего человека
А из тебя уже вряд ли.
Тоже мне, папаша. Умные (али как тебе удобно «взрослые») люди себя так не ведут. Да и пишут пограмотнее.
> злотворное влияние «Камеди Клаба» в виде мата в заголовках
Ну и сидите на своих «аншлагах» да «бенни хилсах». В «Камеди», а так же его ответвлениях, есть много интеллектуального юмора, откинув ширпотреб из пошлости.
> Хабрахабр выкует из тебя настоящего человека
А из тебя уже вряд ли.
Не могли бы вы привести пример интеллектуального юмора из камеди клаба?
Интеллектуальный юмор есть в КВНе, «Вечернем квартале» и шоу «Уральских пельменей». Может быть даже в «ХБ».
В «Камеди Клабе» — матершинный двор — интеллектом и не пахнет. Не в деньгах и приглашенных гостях он меряется. Там остались буквально единичные личности, которые хоть как-то более-менее в рамках цензуры и здравого смысла шутят…
UPD: прочел ваш коммент от 12:24.
У нас явно разные критерии интеллектуального юмора… «Наша Раша» — вообще трэш ещё тот — интеллекта там ещё меньше чем в «КК».
В «Камеди Клабе» — матершинный двор — интеллектом и не пахнет. Не в деньгах и приглашенных гостях он меряется. Там остались буквально единичные личности, которые хоть как-то более-менее в рамках цензуры и здравого смысла шутят…
UPD: прочел ваш коммент от 12:24.
У нас явно разные критерии интеллектуального юмора… «Наша Раша» — вообще трэш ещё тот — интеллекта там ещё меньше чем в «КК».
Да. Разные, как и люди. Что вы все заладили, цензура, матершинный двор, будто это так страшно, что аж… что аж страшно… :) Вы почитайте Есенина или Маяковского и спросите у них, почему они такие гении и не смогли без мата некоторые свои труды написать. Того же Маяковского я читал в детстве, так как у него тоже есть детские стишки, и ничего же. Молодец же он :) Это всего лишь жанр такого искусства, и не более… выражение чувств, эмоций.
Не ожидал увидеть видеть такой пост заминусованным. Видать, вы кого-то за живое задели :)
> появился еще один человек, указывающий, кому место в профессии а кому нет
Неа, вам никто ничего не указывает. Автор просто написал статью на хабр, используя стиль, который, возможно, позволит лучше донести определенные мысли и взгляды, заострить внимание на обсуждаемых проблемах. А вы (и, судя по всему, многие другие) почему-то очень лично текст восприняли. Мне так кажется.
Неа, вам никто ничего не указывает. Автор просто написал статью на хабр, используя стиль, который, возможно, позволит лучше донести определенные мысли и взгляды, заострить внимание на обсуждаемых проблемах. А вы (и, судя по всему, многие другие) почему-то очень лично текст восприняли. Мне так кажется.
А на самом деле вполне предсказуемая ситуация. Чувак :) (он же автор) рассказал свою точку зрения менеджера. А менеджеров уж очень не любят разработчики (а их по голосованию 32%+41%), да и тем более обсуждаются часто возникающие фразы и ситуации, которые направлены не в пользу программистов, а на пользу всего проекта в целом. Вот и обиделись! С кем не бывает! А кто-то даже может на этом спекулирует, мол, поддержку большинство, КАРМАвознесут мое почтение! И будет счастие, тоже смогу опускать комменты и посты! А чо… тоже власть…
no offence, но уж больно типичная позиция «я крутой бизнесмен делаю деньги а вы все исполнители и должны служить мне хорошо» сквозит в этом посте.
В общем, вспомнилось видео про семь красных линий. И в очередной раз подумалось, что человек без опыта работы техническим исполнителем (программистом, разработчиком — как хотите называйте) не особо-то достоин оказаться на позиции управленца в техническом проекте.
В общем, вспомнилось видео про семь красных линий. И в очередной раз подумалось, что человек без опыта работы техническим исполнителем (программистом, разработчиком — как хотите называйте) не особо-то достоин оказаться на позиции управленца в техническом проекте.
Это невозможно — потому что это займет много времени, очень много времени, вы сначала будете ходить два дня, пытаясь выторговать строки по-меньше, рассказывая «вот Вася П. сделал бы, вот я бы сделал бы», потом соберете заседание с таких же тупых и совершенно оторванных от деталей реализации чуваков, после придете и скажете — мы тут подумали, на это уйдет два дня, так и пропишем. Хотя на это по доброму, чтобы оно работало, и работало без проблем, нужно как минимум две недели. Пример утрированный, но это невозможно — зачастую это попросту слишком долго, девелопер уже имел проблемы с чуткой оценкой и попытками ей соответствовать, и ему на*** не надо еще раз это делать. Или другими словами — очень много менеджеров — тупые мудаки, которых непонятно как и за что взяли на работу — они совершенно ничего не понимают в работе тех, кем должны управлять.
По поводу пункта 111: меня как то попросили сделать логарифмическую шкалу с нулем.
Еще бывает разновидность 110 — сделать конечно возможно, но оно не имеет смысла.
Нам как то заказчик дал задание, что то типа психологического теста с подсчетом баллов по хитрой формуле, а по получившимся баллам определять результаты. Так вот, по тестам диапазон баллов получался от 0 до 15, а диапазоны для вычисления результатов были от 0 до 70 (диапазоны для примера, деталей уже не помню).
Долго спорили с заказчиком и доказывали что где то явно ошибка — он реагировал так же как пишет ТС:
«Вы можете как в ТЗ сделать? Можете! Значит делайте».
Нам как то заказчик дал задание, что то типа психологического теста с подсчетом баллов по хитрой формуле, а по получившимся баллам определять результаты. Так вот, по тестам диапазон баллов получался от 0 до 15, а диапазоны для вычисления результатов были от 0 до 70 (диапазоны для примера, деталей уже не помню).
Долго спорили с заказчиком и доказывали что где то явно ошибка — он реагировал так же как пишет ТС:
«Вы можете как в ТЗ сделать? Можете! Значит делайте».
Все 7 выражений суть «Отвали» и «Плевать». Именно они — шаблоны поведения, требующие изучения причин. А причины у компаний свои, что и вызывает острую дискуссию, где каждый прав в контексте своей ситуации.
Это невозможно!
А что, очень часто это действительно невозможно. Особенно если ставившему задачу предложить несколько вариантов когда что-нибудь можно выкинуть из ТЗ и всё станет возможно, а он упирается, ему нужно всё и сразу, все требования критические и нужны обязательно. Тогда это действительно невозможно и точка.
Запомни раз и навсегда, что тестеры не отвечают за качество ПО. Все, что они делают — это измеряют его качество и говорят тебе высокое ли оно, достаточное, либо полная шняга.
Вообще-то отвечают. Контроль качества — не измерение его, а именно контроль — это их функция. Они обладают силой задержать или отменить релиз — если качество низкое, что в свою очередь могут проигнорировать более высокие инстанции.
Безусловно это не значит, что разработчики не отвечают за качество тоже, хоть и несколько иначе. Но вот так вот сделать отдел контроля качества — отделом красивых репортов…
Бывают в некоторых организациях тенденция ответственность за все складывать на того, кто производит. Не проконтролировали процесс — виноваты исполнители, не выполнили план и сорвали сроки — виноваты исполнители и т.д. Если вы в такой организации и помогаете такому процессу жить — не рассчитывайте на прозрачность с одной стороны и с другой на то, что исполнители будут видеть вашу роль хоть сколько нибудь полезной.
Согласен, в некоторых организациях может быть именно так, как Вы описали. Но, может быть чуть иначе:
1. Ответственность за качество продукта несет руководство компании. (см. семейство стандартов ISO 9000 — толковые документы, если используются не только для формальной сертификации компании и получения золотой таблички на стенку офиса)
2. В компании знают более корректный перевод слова «control» — «управление», соответственно, Quality Control переводят, как Управление качеством. Тогда не возникает ассоциаций с «контролером-вахтером-билетером».
3. QA специалист знает, что управление качеством тесно связано с метрологией, а метрология — с различными измерениями. Поэтому, QA специалист знает и умеет производить различные измерения и несомненно делает это в процессе удостоверения качества программного продукта.
4. В процессе обеспечения качества продукта участвуют все сотрудники организации, вовлеченные в процесс его производства.
а в остальном у Вас всё точно :-)
1. Ответственность за качество продукта несет руководство компании. (см. семейство стандартов ISO 9000 — толковые документы, если используются не только для формальной сертификации компании и получения золотой таблички на стенку офиса)
2. В компании знают более корректный перевод слова «control» — «управление», соответственно, Quality Control переводят, как Управление качеством. Тогда не возникает ассоциаций с «контролером-вахтером-билетером».
3. QA специалист знает, что управление качеством тесно связано с метрологией, а метрология — с различными измерениями. Поэтому, QA специалист знает и умеет производить различные измерения и несомненно делает это в процессе удостоверения качества программного продукта.
4. В процессе обеспечения качества продукта участвуют все сотрудники организации, вовлеченные в процесс его производства.
а в остальном у Вас всё точно :-)
Я как-то привык своих людей называть разработчиками (developers)...
А я уж подумала Вы их «чуваками» называете.
Интересно что пост никто не минусует а вот автора в комментах заминусовали)). Мысли в посте все-таки правильные, просто немного категорично высказаны, а в комментах и с переходами на личности. Peace!
Если навести мышку на рейтинг поста, будет видно кол-во голосов «за» и «против»:
Так что и минусуют, и плюсуют пост. Почти поровну.
Так что и минусуют, и плюсуют пост. Почти поровну.
Знал, что будет хабрасуицид. Приятно удивлен, что рейтинг в плюсе. Пока. Очень неоднозначная тема получилась. Явно на больное наступил.
Это же всего лишь статья на Хабре, а не пособие на все случаи жизни и не воинский устав. Я не случайно в самом начале написал, что недолюбливаю шаблоны. Это взгляд со стороны на РЕАЛЬНЫЕ антипаттерны для разработчиков. Допускаю, что многим такое резкое тыканье носом не понравилось. Да и хватает говноменеджеров с их говнометодами и для кого-то некоторые высказывания как красная тряпка. Но это всего лишь статья на Хабре :-) Интересно — читай и делай выводы. Не нравится — проходи мимо. Жизнь сама все по местам расставит.
Если хотя бы одному разработчику статья окажется полезной — писал не зря.
Если хотя бы одному разработчику статья окажется полезной — писал не зря.
Статья по тону такая же негативистская как и паттерны, которые она критикует. Запанибратская стилизация и позиция сверху создают впечатление, что истинная цель — повышение самооценки за чужой счет.
Если хотя бы одному разработчику статья окажется полезной — писал не зря.
Не слишком ли скромный критерий успеха для человека который управляет разработчиками — а они и есть аудитория статьи?
Если хотя бы одному разработчику статья окажется полезной — писал не зря.
Не слишком ли скромный критерий успеха для человека который управляет разработчиками — а они и есть аудитория статьи?
Статья — хорошая, давно ждал подобного, чтобы не спорить с отдельными разработчиками по каждому поводу. Взятая позиция в комментариях — неудачная. Не потому что неправильная (а как тут вообще можно судить о правильности?), а потому что направлена на вызов баттхерта, и успешно его вызывает. Вот и бьют в ответ, как могут. Хотя определенно есть и возражения по делу.
> Явно на больное наступил
Ага, приятно так считать, когда многие не согласны со сказанным. Типа это дураки злобные, а я в белом.
Ага, приятно так считать, когда многие не согласны со сказанным. Типа это дураки злобные, а я в белом.
Напомнило черную книгу менеджера.
На Хабре есть замечательная статья Как из болота вытягивать ITшника или об общении в стрессовых ситуациях . Почти все приведенные «антипаттерны» из вашего топика отлично укладываются в модель реакций из той статьи (отрицание — 001, 011 гнев — 010, 011, 100, торг — 110, 111, депрессия, принятие ).
Таким образом, использование этих антипаттернов подчиненными Вам людьми не что иное, как нормальная человеческая реакция. Скажу больше — такая реакция чаще всего говорит не в Вашу пользу. Не хотите получать антипаттерны в ответах, не пользуйтесь антипаттернами в вопросах. Поменяйте модель вашего поведения и люди не будут Вам в ответ говорить эти слова. Ваша задача, как руководителя: не допускать перехода собеседника в состояние гнев и депрессия, а стремиться максимально быстро дойти до состояния принятия.
Таким образом, использование этих антипаттернов подчиненными Вам людьми не что иное, как нормальная человеческая реакция. Скажу больше — такая реакция чаще всего говорит не в Вашу пользу. Не хотите получать антипаттерны в ответах, не пользуйтесь антипаттернами в вопросах. Поменяйте модель вашего поведения и люди не будут Вам в ответ говорить эти слова. Ваша задача, как руководителя: не допускать перехода собеседника в состояние гнев и депрессия, а стремиться максимально быстро дойти до состояния принятия.
А давайте на примере разберем. Ситуация следующая. От клиента пришла критичная бага, тестеры посмотрели — воспроизводится, назначили на Вас Артем. На следующий день я у Вас интересуюсь «Артем, что у нас с багой 4567, до сих пор открыта, а приоритет — топовый?». Вы мне отвечаете: «А у меня на компе все работает, не могу воспроизвести». Немного утрирую, но тем не менее что я сделал не так?
Не наладили коммуникацию между Артемом (у которого не воспроизводится) и QA (у которых воспроизводится)?
А что значит «не наладили» если до этого Артем и QA общались друг с другом много, много раз?
Ок, если рассматривать ситуацию налаженных коммуникаций, то может тогда следует вникнуть в причину, по которой QA и разработчик так и не смогли сделать так, чтоб баг воспроизводился у разработчика? Не рассматриваете ситуацию, что QA и разраб всю ночь пытались воспроизвести у разраба, но так и не смогли и не нашли причину, по которой в окружении разраба всё работает, а в окружении тестера — нет?
Очень даже допускаю, что ситуацию объясняет, но никак не приближает нас к ее решению. + Все-таки что я сделал не так? Вернемся к нашему самому первому вопросу. Вы считаете ответ «А у меня на компе все работает» приемлемым?
Ну если вы при этом уточнили, что проблема в том, что не могут понять почему в одном месте воспроизводится, а в другом нет, и при этом они работают над проблемой — вы можете лишь ждать.
Ответ «А у меня на компе все работает» — нет, а вот ответ «А у меня на компе все работает, не могу воспроизвести» — для меня было бы приемлемо и я бы полез изучать вопрос глубже.
Ответ «А у меня на компе все работает» — нет, а вот ответ «А у меня на компе все работает, не могу воспроизвести» — для меня было бы приемлемо и я бы полез изучать вопрос глубже.
Т.е. в конечном итоге мы пришли к общему знаменателю как я надеюсь. И для Вас, и для меня ответ «А у меня на компе все работает» является неприемлемым в такой ситуации. И тем не менее тысячи разработчиков каждый день так делают. О чем собственно и статья.
Заметьте, что вы пришли к общему знаменателю только после серии уточняющхе комментов. Могло быть «у меня не воспроизводится и они не могут повторить еще раз» или «у меня не воспроизводится, я послал письмо с уточняющими вопросами и они пока не отвечают». Мне кажется, или в каждом пункте нужно пояснение с разбором РАЗНЫХ ситуаций или этот список тривиален. То есть у тех, кто не понимает о чем идет речь такое вызовет только раздражение а остальным просто ничего не даст
Был у меня на прошлой работе баг… Воспроизводился только в Сафари, только на Маке, у ПМ в ЛосАнжелесе. Ответ был — не могу воспроизвести. Ну не покупать же Мак для мелкого бага с отображением :)
А баг тот так три месяца и провисел пока я там еще работал…
А баг тот так три месяца и провисел пока я там еще работал…
Очень интересно, не связано ли это с ошибкой в обработке/парсинге дат в Сафари на Маке…
У меня на такой случай 2 виртуалки: Виндовс для IE и Mac для сафари и iOS(хотя iPad в офисе был, но бывал занят).
А нельзя было удалённо подключиться к майку менеджера для отладки? Включить логгирование для него? Виртуалки с макос бывают?
Ну, проблема в том что разработка была только на удаленном сервере — локально поднять было очень сложно все зависимости, просто посмотреть удаленно не вариант, мак тот был не девелоперский и доступа к сандбоксам у него не было, виртуалку под убунтой ставить чтобы она могла конектиться через впн к удаленному серверу я не умел.
Вобщем городить огород на несколько человекочасов ради визуального бага не всегда даже на маке имевшем место ( на других вроде не было, не помню уже ) — было слишком уж.
Вобщем городить огород на несколько человекочасов ради визуального бага не всегда даже на маке имевшем место ( на других вроде не было, не помню уже ) — было слишком уж.
Я не говорю о клинических случаях кретинизма среди подчиненных. Ваш пример говорит о некомпетентности сотрудника и подтверждает Ваши тезисы. Но есть примеры, которые Ваши тезисы опровергают (см. мой комментарий ниже).
Т.е. условно «все матери — женщины, но не все женщины — матери». Я согласен, что плохие специалисты часто используют Ваши антипаттерны. Я не согласен с тем, что использование антипаттернов говорит о том, что специалист — плохой и не может носить гордое звание «разработчика»
Т.е. условно «все матери — женщины, но не все женщины — матери». Я согласен, что плохие специалисты часто используют Ваши антипаттерны. Я не согласен с тем, что использование антипаттернов говорит о том, что специалист — плохой и не может носить гордое звание «разработчика»
Артем,
Нескромный вопрос, но тем не менее, с каким количеством разработчиков Вам приходилось иметь дело по жизни в качестве руководителя? Моя практика непосредственной работы с сотнями из них подтверждает, что даже самые талантливые и крутые из них регулярно выдают эти самые паттерны и именно в режиме «клинических случаев кретинизма», как Вы их описываете. А они далеко не кретины. Я общался со многими другими лидерами айтишных команд и у них вся та же симптоматика регулярно возникает. Не встречались еще мне исключения. Неужели Вам совсем приведенные шаблоны не знакомы в вашем коллективе?
Нескромный вопрос, но тем не менее, с каким количеством разработчиков Вам приходилось иметь дело по жизни в качестве руководителя? Моя практика непосредственной работы с сотнями из них подтверждает, что даже самые талантливые и крутые из них регулярно выдают эти самые паттерны и именно в режиме «клинических случаев кретинизма», как Вы их описываете. А они далеко не кретины. Я общался со многими другими лидерами айтишных команд и у них вся та же симптоматика регулярно возникает. Не встречались еще мне исключения. Неужели Вам совсем приведенные шаблоны не знакомы в вашем коллективе?
У меня ситуации бывают и посложнее в том смысле, что мне приходится доказывать разработчикам, что они не правы, и при этом я не являюсь их руководителем :). И шаблоны мне ваши знакомы. Я просто не пытаюсь оценивать уровень разработчика по факту использования этих шаблонов. Я просто стараюсь решить возникшую проблему, не давая оппонентам лишних поводов использовать шаблон.
Вы же сами говорите, что даже самые талантливые и крутые используют шаблоны. И они не кретины. А это значит, что на лицо «классический дебют»: е2 — е4, дурак — сам дурак и т.п. В этом случае нужно просто рвать шаблон пока отрицание оппонента не сменилось гневом. Иногда достаточно просто спросить: что тебе нужно, Вася, чтобы решить проблему в кратчайший срок?
Вы же сами говорите, что даже самые талантливые и крутые используют шаблоны. И они не кретины. А это значит, что на лицо «классический дебют»: е2 — е4, дурак — сам дурак и т.п. В этом случае нужно просто рвать шаблон пока отрицание оппонента не сменилось гневом. Иногда достаточно просто спросить: что тебе нужно, Вася, чтобы решить проблему в кратчайший срок?
Дак и я не оцениваю. Опять же Вы приписываете мне те качества, которых у меня нет. Просто я отношусь к разработчикам как к взрослым, самостоятельным личностям, отвечающим за свои слова и поступки, а не как к детям маленьким, которых нужно оберегать, холить и лелеять, а не расстраивать суровыми реальностями окружающего мира.
Зря :) Разработчиков как раз зачастую надо оберегать, холить и лелеять :) habrahabr.ru/post/146169/
«Я не согласен с тем, что использование антипаттернов говорит о том, что специалист — плохой и не может носить гордое звание «разработчика»»
+ Тут Вы мне приписываете высказывание, которого я не говорил.
+ Тут Вы мне приписываете высказывание, которого я не говорил.
Так название статьи об этом говорит: О чем НЕ говорят разработчики или 7 любимых выражений программистов
При этом в вводной части Вы поясняете, что термин «программист» — носит негативную окраску, а «разработчик» — наоборот.
А я просто Вам отвечаю, что самые лучшие разработчики употребляют антипаттерны, но от этого не перестают быть лучшими и не перестают быть разработчиками.
Моя мысль, если кратко: Лучше употреблять антипаттерны в речи, но при этом в итоге решать проблему, чем не употреблять и при этом не решать проблему. Плохой, потому что не справился, а не потому что позволил себе высказаться в процессе.
При этом в вводной части Вы поясняете, что термин «программист» — носит негативную окраску, а «разработчик» — наоборот.
А я просто Вам отвечаю, что самые лучшие разработчики употребляют антипаттерны, но от этого не перестают быть лучшими и не перестают быть разработчиками.
Моя мысль, если кратко: Лучше употреблять антипаттерны в речи, но при этом в итоге решать проблему, чем не употреблять и при этом не решать проблему. Плохой, потому что не справился, а не потому что позволил себе высказаться в процессе.
Сложно с Вашей мыслью не согласиться, но все-таки речь, как правило, имеет отношение к сознанию. Как говорят «что на уме, то и на языке». И употребление антипаттернов в речи таки непосредственно коррелирует с поведенческими шаблонами.
А если посмотреть на ситуацию с другой стороны? Человек, вступивший в диалог обозначил свое отношение к проблеме, пусть и с использованием антипаттерна. Т.е. он поднял «флажок», что проблема выводит его из зоны комфорта. И вы видите этот флажок и можете на него реагировать — помочь, подсказать, подключить дополнительные ресурсы. А другой просто промолчал. Вы восприняли его молчание, как согласие и ждете сообщения о решении проблемы. А в итоге время упущено, а проблема так и не решена.
+ Я думаю Вы знакомы с таким выразительным приемом как гипербола. Меня пугает, что столько людей все написанное восприняли буквально.
Скорее всего, просто кинули на Артема баг в джире, вместо того, чтобы, зная, что Артем так может сказать, подойти к нему, обьяснить, как важно починить именно этот баг, убедиться, что у Артема все есть, чтобы с этим разобраться и сделать вовремя.
Вы забавно описали эти «анти-паттерны», и правда такое слышишь довольно часто. Но из вашего текста складывается ощущение, что вы относитесь к такому антипаттерновому типу руководителей, которые основную свою задачу видят в заполнении полей в ишшью трекере и перекидывания тасков туда-сюда (надеюсь, это не так), вот вас и минусуют.
В чем вы видите свои обязанности, как руководителя? Просто я понимаю задачу тимлида именно в том, чтобы создать такие условия, так устроить команду, чтобы такие антипаттерны не возникали. Отвественность за их возникновение лежит на тимлиде и разработчике поровну.
Вы забавно описали эти «анти-паттерны», и правда такое слышишь довольно часто. Но из вашего текста складывается ощущение, что вы относитесь к такому антипаттерновому типу руководителей, которые основную свою задачу видят в заполнении полей в ишшью трекере и перекидывания тасков туда-сюда (надеюсь, это не так), вот вас и минусуют.
В чем вы видите свои обязанности, как руководителя? Просто я понимаю задачу тимлида именно в том, чтобы создать такие условия, так устроить команду, чтобы такие антипаттерны не возникали. Отвественность за их возникновение лежит на тимлиде и разработчике поровну.
Установили кривую систему трекинга багов, в которой почему-то тестер не указывает конфигурацию своей системы.
Если ошибка настолько уникальна, что воспроизводится только на машине тестера, то у программиста должна быть возможность удаленно или непосредственно зайти на тестерскую машину, скомпилировать и прогнать программу. Еще можно использовать виртуальные машины, это удобнее.
ПС. Ну или наняли плохово программиста, который вам банально врет.
Если ошибка настолько уникальна, что воспроизводится только на машине тестера, то у программиста должна быть возможность удаленно или непосредственно зайти на тестерскую машину, скомпилировать и прогнать программу. Еще можно использовать виртуальные машины, это удобнее.
ПС. Ну или наняли плохово программиста, который вам банально врет.
Уточню по поводу «антипаттернов» в вопросах.
А у меня на компе работает чаще всего является ответом на наезд без конкретики из серии «У нас ничего не работает!!!». Пользователь пишет это в BugTracking, копию отправляет начальству, и при этом у меня нет никаких данных, чтобы начать анализ проблемы. И в ответ я включаю «отрицание»
Какой идиот это писал? — это обычно реакция на просьбу не в зоне ответственности исполнителя. Например: «Привет, там Вася два месяца писал код, но не успел закончить до отпуска. Заказчику я пообещал, что фичу накатим сегодня, там кое-что поменять надо, но дел буквально на 5 минут. Ты разберись и сделай по-быстренькому»
Это невозможно и Я такую ерунду делать не буду обычно случаются, когда начальство считает, что лучше меня разбирается в системе и моем коде. Или когда «хотелка» выходит за рамки треугольника «срок-бюджет-качество», при этом начальство треугольник расширять не хочет. Невозможно в данном контексте относится к нереальному по моему мнению бюджету/сроку, а Ерунда к моему нежеланию снижать качество продукта костылями.
А у меня на компе работает чаще всего является ответом на наезд без конкретики из серии «У нас ничего не работает!!!». Пользователь пишет это в BugTracking, копию отправляет начальству, и при этом у меня нет никаких данных, чтобы начать анализ проблемы. И в ответ я включаю «отрицание»
Какой идиот это писал? — это обычно реакция на просьбу не в зоне ответственности исполнителя. Например: «Привет, там Вася два месяца писал код, но не успел закончить до отпуска. Заказчику я пообещал, что фичу накатим сегодня, там кое-что поменять надо, но дел буквально на 5 минут. Ты разберись и сделай по-быстренькому»
Это невозможно и Я такую ерунду делать не буду обычно случаются, когда начальство считает, что лучше меня разбирается в системе и моем коде. Или когда «хотелка» выходит за рамки треугольника «срок-бюджет-качество», при этом начальство треугольник расширять не хочет. Невозможно в данном контексте относится к нереальному по моему мнению бюджету/сроку, а Ерунда к моему нежеланию снижать качество продукта костылями.
Артем, возможно я не прав, но все-таки в большинстве случаев для приведенных Вами ситуаций объяснения гораздо проще и банальнее. На тему «Какой идиот это писал?» даже уже мем есть про «фатальный недостаток» любого кода. Это не отрицает возможности и существования более сложных ситуаций, описанных Вами.
«Какой идиот это писал?» — это просто выплеск эмоций. Чаще всего возникает как реакция на неожиданную стрессовую ситуацию. Когда человеку на ногу падает кирпич, человек, конечно, может прореагировать спокойно. Но я не буду осуждать такого человека, если он позволит себе пару крепких выражений. И это точно не будет являться для меня критерием оценки его, как личности в целом.
Мне кажется Вы опять усложняете и ищете оправдания. Если для разработчика покапаться в чужом коде — неожиданная стрессовая ситуация, то это как бы немножко не профессионально?
Править чужой код всегда стресс, но профессионал с этим справляется. Если за спиной не стоять с секундомером. Я утрирую, но в штатной ситуации править чужой код обычно не заставляют.
Есть очень много разных штатных ситуаций, почитайте например про collective code ownership. Да и в опенсурсе сплошь и рядом. Конечно, это требует навыка.
> проще и банальнее
Самое простое и банальное — программисты зачастую слабы в навыках «торговаться», «убеждать» (если бы они были сильны — они бы сделали бы намного более выгодную карьеру в продажах металлопроката, например).
И они уже сталкивались с тем, что при попытке заикнуться, что реализовать можно, но это потребует такого-то времени (ради которого придется двигать другие задачи, которые уже на них) или других ресурсов, ими нещадно манипулировали, впихивая задачу до кучи к имеющимся,
приходилось работать ночами и выходными, а потом получать лишение премии или неласковые слова за низкое качество, срыв сроков и завал не только этой задачи, но и остальных.
Т.е. они опытным путем пришли к тому, что тупо идти в отказ («невозможно») — более выигрышная стратегия, позволяющая не заколебаться и выпускать свои задачи в срок и с годным качеством.
И это не обязательно проблема в вашем менеджменте, могут быть и последствия травмы полученной у предыдущего работодателя.
Самое простое и банальное — программисты зачастую слабы в навыках «торговаться», «убеждать» (если бы они были сильны — они бы сделали бы намного более выгодную карьеру в продажах металлопроката, например).
И они уже сталкивались с тем, что при попытке заикнуться, что реализовать можно, но это потребует такого-то времени (ради которого придется двигать другие задачи, которые уже на них) или других ресурсов, ими нещадно манипулировали, впихивая задачу до кучи к имеющимся,
приходилось работать ночами и выходными, а потом получать лишение премии или неласковые слова за низкое качество, срыв сроков и завал не только этой задачи, но и остальных.
Т.е. они опытным путем пришли к тому, что тупо идти в отказ («невозможно») — более выигрышная стратегия, позволяющая не заколебаться и выпускать свои задачи в срок и с годным качеством.
И это не обязательно проблема в вашем менеджменте, могут быть и последствия травмы полученной у предыдущего работодателя.
Такая позиция мне гораздо ближе и она на мой взгляд более реалистична. Знакомая ситуация. Тем не менее в целом я считаю разработчиков, умеющих грамотно объяснять и отстаивать свою позицию, более ценными, чем тупо уходящих в отказ и при прочих равных предпочту первых. Отсюда и шаблон. + У многих он возникает от некоторой общей инфантильности и интровертности.
Отстаивать позицию имеет смысл только перед компетентными людьми. А некомпетентный мои доводы не поймет, но поймет, что задача решаема и включит административный ресурс. И ладно бы мне просто поставили задачу, мне еще установят срок ее решения (со мной его не согласовав) и потом спросят за качество. Да, еще мне будет делегирована вся ответственность за возможный «провал», но возможная «победа» пойдет в зачет «креативщику», а не мне. У нас в конторе, как в футболе — выигрывает «команда», а проигрывает «вратарь». Поэтому, когда возможно, я отвечаю: «Невозможно!!!».
З.Ы. Это тоже гипербола, прошу не понимать буквально
З.Ы. Это тоже гипербола, прошу не понимать буквально
Просто описание моего предыдущего места работы! Самое смешное — там уже растеряли весь отдел разработки и были вынуждены заполнить его студентами. Интересно на кого теперь давят эти администраторы и как делают карьеру.
Зачем работать только в таком месте, где все так гиперболически как у Вас описано?
Идеальных мест не бывает. Во всяком случае, я таких не встречал. А работу делать надо. Чтобы кто-то имел возможность свободно и радостно творить, кто-то другой должен обеспечивать ему комфортную инфраструктуру. В нашей стране почти всю инфраструктуру (ЖКХ, транспорт, связь) обеспечивают «монстры» из моего гиперболического примера. И всем этим монстрам нужны ИТ-специалисты. У этих специалистов своя мотивация: кто-то работает за опыт, который не смог бы получить в маленькой организации; кто-то держится за соц. пакет и белую зарплату; а кто-то пытается сделать действительность чуточку лучше «изнутри». Есть такой старый анекдот про чукчу: «Ну, что, жена… Этих детей отмоем или новых наделаем?» Оба подхода имеют право на жизнь. Вы предлагает делать новых, а кто-то старается отмыть старых
Нашел, кстати, у Вас в Избранном статью Основная особенность наших разработчиков (раньше ее не читал). Там автор удивляется тому, что русский программист слишком часто говорит «невозможно». В комментариях (а их более трех сотен) куча примеров ситуаций, объясняющих почему мы это делаем.
Там автор привел совершенно конкретную ситуацию в которой разработчик упёрся без видимых на то оснований. Плюс автор поработал с разработчиками из других стран и культур и ему есть с чем сравнивать. Я впрочем тоже. И я с ним полностью согласен, что неоправданная упертость (stubbornness) одна из отличительных характеристик разработчиков из России, которая порою может перевешивать все их многочисленные достоинства.
Разве дело программистов приоритезация задач? Программист называет свою оценку, а PM уж решает выполнять или нет и в каком порядке. Если задачи оценены, то «впихивание до кучи» приводит только к разрастанию кучи во времени и отодвигает релиз/сдачу этапа. Если менеджемент этого не понимает, надо его учить или увольняться.
У нас это бывает так: в начале месяца ПМ говорит «задача А очень важная, давайте постараемся её закрыть, по итогам всем будет премия». Но в середине месяца прилетают задачи Б, Ц, Д, которые срочные и делать надо сейчас. В итоге программист вынужден делать всякую текучку, но манагер искренне верит, что все мотивированы на задачу А и тоже её попытаются сделать.
А программист не намекает менеджеру, что в месяце фиксированное количество дней и что само переключение между задачами небесплатно? Есть ли что-то типа кабан доски с фиксированным work-in-progress? Как отслеживается трудоемкость задач? Что менеджер думает о статье Спольски «О вреде премирования?
Менеджер сам в мыле лавирует между прилетающими задачами и выбирает, какую задачу не сделать, чтобы обидеть не слишком важного начальника. Намекать не нужно, все всё понимают, но есть хотелка от собственника срочная, есть отчётность для непонятно откуда возникших аудиторов, и в итоге (с т.з. основных заказчиков) программисты целый месяц балду пропинали и ничего не сделали.
Кстати, одно время как-бы-скрам был, но на планирование заказчики вскоре перестали ходить, потому что поняли, что всё, что им обещано было, так или иначе будет вытеснено внеплановыми задачами.
Кстати, одно время как-бы-скрам был, но на планирование заказчики вскоре перестали ходить, потому что поняли, что всё, что им обещано было, так или иначе будет вытеснено внеплановыми задачами.
Имхо премия только дестимулирует в вашем случае и менеджер не выполняет часть своей работы по донесению до заказчиков вреда от переключений работы вы ему такое говорили? (только переформулируя позитивно)
Смотря как к ней относиться. Если относится как к лотерее — то нормально. Особо не расчитывать, но в редких случаях она достижима и нужно лишь чуть напрячься — и вот она (главное, в слове «чуть», а то может всё сорваться и демотивировать). Заказчикам бесполезно доносить, их волнуют только собственные проекты. Поэтому такой priority queue — кто главнее, того и делаем. Сделали — переключаемся на следующего по рангу, пока более главный не прервёт. В принципе, все уже настолько привыкли к просранным планам, что всем пофиг.
Вы же сами писали, что разработчики говорят «это невозможно» чтобы пропустить премиальную задачу — то есть дестимулирует решать другие задачи.
Если всем плевать на прозрачные планы можно начать работать спокойно в стиле канбана — не берётся за новое пока не сделаем текущее + expedite lane с фиксированным wip на срочные таски
Если всем плевать на прозрачные планы можно начать работать спокойно в стиле канбана — не берётся за новое пока не сделаем текущее + expedite lane с фиксированным wip на срочные таски
Наверное, так и получается, только без канбан-досок и прочего фетиша. А терминологией я не владею )) translate.google.com/#en/ru/expedite%20lane, а к wip ближайшее словарное слово — wipe ))
Канбан — просто способ визуализации общий принцип — не берем новое, пока кто-то не освободится (вернее пока количество задач в работе не становится меньше чем экспериментально подобранное число work in progress) есть отдельная полоса пропускания для срочных задач — expedite lane, но туда тоже нельзя помещать больше определённого количества. Отслеживаем среднее время прохождение через процесс и очереди на каждом этапе.
Вы описали случай, когда менеджер плохо справляется со своими обязанностями. Это его работа — разъяснять и отпинывать все что не согласуется с целями. В т.ч. и непосредственное руководство. Потому что ситуация гонки задач классическая и так всегда и везде.
Неужели с точки зрения манагеров наши ответы именно это означают? Отсутствие взаимопонимания между менеджерами и разработчиками это путь к фейлу прямой.
Судя по отсутствию пункта 000 автор сам не до конца знает то, подо что стилизует список :)
За остальными пунктами может скрываться примерно по миллиону разных ситуаций.
Например, «это сделать невозможно» может обозначать лень, противоречие в ТЗ, слишком большую трудоемкость и т.п.
Если у нас есть хороший менеджер и средний разработчик, то первый наверняка выяснить у второго почему невозможно и какие есть варианты удовлетворить потребности клиента. Если у нас хороший (с точки зрения навыков коммуникации) разработчик, то он может скомпенсировать посредственность менеджера тем, что сам попытается выяснить, что надо в итоге и предложит удовлетворить потребности конечного пользователя другим способом.
Думаю, еще в этом ответе — «это сделать невозможно» — раздражает упрямая категоричность.
Как и в тоне автора поста.
Будь гибче, чувак!
За остальными пунктами может скрываться примерно по миллиону разных ситуаций.
Например, «это сделать невозможно» может обозначать лень, противоречие в ТЗ, слишком большую трудоемкость и т.п.
Если у нас есть хороший менеджер и средний разработчик, то первый наверняка выяснить у второго почему невозможно и какие есть варианты удовлетворить потребности клиента. Если у нас хороший (с точки зрения навыков коммуникации) разработчик, то он может скомпенсировать посредственность менеджера тем, что сам попытается выяснить, что надо в итоге и предложит удовлетворить потребности конечного пользователя другим способом.
Думаю, еще в этом ответе — «это сделать невозможно» — раздражает упрямая категоричность.
Как и в тоне автора поста.
Будь гибче, чувак!
Такое ощущение что статья написана не разработчиком, а каким-нибудь менеджером. Причем таким матерым менеджером, который в разработке никогда не участвовал, а сразу заканчичвал «Менеджмент и маркетинг» (это, кстати, в моем понимании ругательство и оскорбление :))
Но чтобы не быть голословным нужно аргументировать. Так что детализирую свои претензии по пунктам.
1. А у меня на компе работает. «Я разработчик, я не хочу настраивать ИДЕ, я хочу клац-клац, Ф5 и в продакшн». Слава богу мы уже не те программисты, которые картриджы меняли. Если у меня на компе работает — значит код рабочий, пускай админ разбирается с косяками настройки окружения. Если код написан в соответствии с требованиями, на указанном в требованиях языке, на указанной версии языка, с разрешенными требованиями библиотеками — не проблема программиста заниматься его запуском где-либо кроме собственной машины.
2. До тех пор пока можно порезаться даже безопасной бритвой, если проявить смекалку и фантазию — я буду называть мудаков мудаками. Тем более что режусь я регулярно, мудак эдакий. Задача разработчика — предоставить решение поставленной задачи в поставленных условиях. Если клиент потенциально — дебил способный на что угодно — значит тот кто составлял ТЗ должен был учесть это. Менеджер должен был учесть это и сказать аналитику, аналитик должен был учесть это и описать в ТЗ. А разработчик должен просто предоставить решение, соответствующее требованиям. Если в требованиях чего-то нет — в решении этого тоже может не быть.
3. Тестеры нифига не протестировали, чем они вообще занимаются? Если я — последний рубеж — прошу разделить зарплату отдела тестирования между отделом разработки и упразднить этот отдел «контроля качества» за необоснованностью его существования. Одно дело если тестер попытался что-то сделать, а оно в принципе не работает, но тут смотри пункт 1 — у меня на компьютере запускается. Если нет то это клинический случай. А если тестер нашел хитрый баг на специфической комбинации параметров при совмещении модулей от нескольких разработчиков — то на то он и нужен, этот тестер.
4. Если это писал я то я идиот. Иногда полезно это осознавать. Если речь идет о формулировке то я согласен — не стоит так грубо говорить в команде, слова можно подобрать другие. Но если код — говнокод — его автор должен быть найден и тыкнут носом. Даже если это я сам. В образовательных целях, очевидно же что кто-то умнее и опытнее, а кто-то нет, как можно передать опыт от человека к человеку или осознать что ты стал лучше чем был когда-то если не находить говнокод и не признавать его низкое качество?
5. Формулировка дурацкая, конечно. Но есть такая хорошая шутка что надпись 99% Complete при установке виндоус радует только первые полчаса. Любой разработчик знает что бывает вроде бы мелкая проблема решение которой может потребовать неопределенно долгого времени. А так как разработчики это инженеры, а не менеджеры, они не приучены ни врать ни блефовать, и если не могут дать точный ответ о необходимом времени — дают такой точный ответ, какой умеют. Потому что если я скажу «будет готово через 3 часа», хотя сам в этом не уверен и через три часа готово не будет я не смогу как менеджер сказать «Ну, не получилось, нужно еще три недели», вместо этого я буду чувствовать себя плохо, моя мотивация упадет, самооценка пострадает, эффективность понизится, лояльность к команде, поставившей меня в такие условия ухудшится… ну в общем я надеюсь понятно для менеджера выразился.
Вообще менеджер или тим-лид это «прокладка» между разработчиком и человеком. И он обязан уметь понимать язык разработчика и переводить на человеческий. Поэтому он должен выслушать тираду про проблему с jQuery, задать наводящие вопросы и в документе написать «ориентировочно 3 часа, высокий риск задержки».
6. Да, возможно всё. Но мне несколько раз доводилось говорить «Это невозможно». Почему? Это была экспертная оценка аналитика, исходя из понимания сложности задачи, затрат на ее выполнение и имеющихся ресурсов. Если разработчик говорит что что-то невозможно значит этому есть причины. Можно до них докопаться, выяснить насколько они оправданы и либо согласиться с такой оценкой либо найти пути решения. Но если разработчик говорит «это невозможно» не вдаваясь в подробности менеджеру, с которым давно работает — этому менеджеру следует подумать, скорее всего его умственные способности были оценены негативно.
Впрочем, этот пункт — поле для отдельной полемики об устанавливаемых задачах и предоставляемых ресурсах на их решение. Как говорится «Менеджер думает что если взять 9 женщин то можно родить ребенка за месяц».
7. Если у человека есть определенная профессиональная гордость и она обоснована — разве это не хорошо? Если время человека стоит больше, значительно больше чем время другого человека, который мог бы решить эту задачу и он сообщает об этом — это замечательно! Это возможность оптимизации затрат. Конечно иногда нецелевое использование ресурсов оправдано, но чаще всего нанятый владельцем бизнеса менеджер просто не задумывается о том, что забивает гвозди микроскопом и выступает с позиции «тебе за это платят — делай что я говорю». Очень печальная ситуация, которая не способствует развитию, зато способствует деградации, потере самоуважения, понижению мотивации, ухудшению отношения к коллективу, толкающему на это, пониижению эффективности труда разработчика и в результате приводит к увольнению. И должно уволиться несколько хороших разработчиков чтобы высокое начальство наконец догадалось что проблема в менеджере и наконец-то от него избавилось.
Если разработчику предложить помыть полы в рабочее время он скорее всего тоже не согласится. Причем чам выше зарплата этого разработчика тем более вероятно что он не согласится. Так вот есть в нашей области задачи, сложность которых аналогична мытью полов и является оскорбительной для достигнутого человеком профессионального уровня. И чем выше уровень — тем больше таких задач. Хотя у нас, конечно, люди как правило работы не боятся и сеньер девелоперы бодро носят мебель или коробки с чем попало, потому что у компании видимо нет денег на грузчиков.
Извиняюсь за пропитанный негативом к менеджменту текст. Но люди считающие других «ресурсами» несколько надоели своим отсутствием желания понимать область, в которой работают. Особенно ту часть области где оказывается что вокруг тоже люди, ничуть не хуже себя любимого.
Но чтобы не быть голословным нужно аргументировать. Так что детализирую свои претензии по пунктам.
1. А у меня на компе работает. «Я разработчик, я не хочу настраивать ИДЕ, я хочу клац-клац, Ф5 и в продакшн». Слава богу мы уже не те программисты, которые картриджы меняли. Если у меня на компе работает — значит код рабочий, пускай админ разбирается с косяками настройки окружения. Если код написан в соответствии с требованиями, на указанном в требованиях языке, на указанной версии языка, с разрешенными требованиями библиотеками — не проблема программиста заниматься его запуском где-либо кроме собственной машины.
2. До тех пор пока можно порезаться даже безопасной бритвой, если проявить смекалку и фантазию — я буду называть мудаков мудаками. Тем более что режусь я регулярно, мудак эдакий. Задача разработчика — предоставить решение поставленной задачи в поставленных условиях. Если клиент потенциально — дебил способный на что угодно — значит тот кто составлял ТЗ должен был учесть это. Менеджер должен был учесть это и сказать аналитику, аналитик должен был учесть это и описать в ТЗ. А разработчик должен просто предоставить решение, соответствующее требованиям. Если в требованиях чего-то нет — в решении этого тоже может не быть.
3. Тестеры нифига не протестировали, чем они вообще занимаются? Если я — последний рубеж — прошу разделить зарплату отдела тестирования между отделом разработки и упразднить этот отдел «контроля качества» за необоснованностью его существования. Одно дело если тестер попытался что-то сделать, а оно в принципе не работает, но тут смотри пункт 1 — у меня на компьютере запускается. Если нет то это клинический случай. А если тестер нашел хитрый баг на специфической комбинации параметров при совмещении модулей от нескольких разработчиков — то на то он и нужен, этот тестер.
4. Если это писал я то я идиот. Иногда полезно это осознавать. Если речь идет о формулировке то я согласен — не стоит так грубо говорить в команде, слова можно подобрать другие. Но если код — говнокод — его автор должен быть найден и тыкнут носом. Даже если это я сам. В образовательных целях, очевидно же что кто-то умнее и опытнее, а кто-то нет, как можно передать опыт от человека к человеку или осознать что ты стал лучше чем был когда-то если не находить говнокод и не признавать его низкое качество?
5. Формулировка дурацкая, конечно. Но есть такая хорошая шутка что надпись 99% Complete при установке виндоус радует только первые полчаса. Любой разработчик знает что бывает вроде бы мелкая проблема решение которой может потребовать неопределенно долгого времени. А так как разработчики это инженеры, а не менеджеры, они не приучены ни врать ни блефовать, и если не могут дать точный ответ о необходимом времени — дают такой точный ответ, какой умеют. Потому что если я скажу «будет готово через 3 часа», хотя сам в этом не уверен и через три часа готово не будет я не смогу как менеджер сказать «Ну, не получилось, нужно еще три недели», вместо этого я буду чувствовать себя плохо, моя мотивация упадет, самооценка пострадает, эффективность понизится, лояльность к команде, поставившей меня в такие условия ухудшится… ну в общем я надеюсь понятно для менеджера выразился.
Вообще менеджер или тим-лид это «прокладка» между разработчиком и человеком. И он обязан уметь понимать язык разработчика и переводить на человеческий. Поэтому он должен выслушать тираду про проблему с jQuery, задать наводящие вопросы и в документе написать «ориентировочно 3 часа, высокий риск задержки».
6. Да, возможно всё. Но мне несколько раз доводилось говорить «Это невозможно». Почему? Это была экспертная оценка аналитика, исходя из понимания сложности задачи, затрат на ее выполнение и имеющихся ресурсов. Если разработчик говорит что что-то невозможно значит этому есть причины. Можно до них докопаться, выяснить насколько они оправданы и либо согласиться с такой оценкой либо найти пути решения. Но если разработчик говорит «это невозможно» не вдаваясь в подробности менеджеру, с которым давно работает — этому менеджеру следует подумать, скорее всего его умственные способности были оценены негативно.
Впрочем, этот пункт — поле для отдельной полемики об устанавливаемых задачах и предоставляемых ресурсах на их решение. Как говорится «Менеджер думает что если взять 9 женщин то можно родить ребенка за месяц».
7. Если у человека есть определенная профессиональная гордость и она обоснована — разве это не хорошо? Если время человека стоит больше, значительно больше чем время другого человека, который мог бы решить эту задачу и он сообщает об этом — это замечательно! Это возможность оптимизации затрат. Конечно иногда нецелевое использование ресурсов оправдано, но чаще всего нанятый владельцем бизнеса менеджер просто не задумывается о том, что забивает гвозди микроскопом и выступает с позиции «тебе за это платят — делай что я говорю». Очень печальная ситуация, которая не способствует развитию, зато способствует деградации, потере самоуважения, понижению мотивации, ухудшению отношения к коллективу, толкающему на это, пониижению эффективности труда разработчика и в результате приводит к увольнению. И должно уволиться несколько хороших разработчиков чтобы высокое начальство наконец догадалось что проблема в менеджере и наконец-то от него избавилось.
Если разработчику предложить помыть полы в рабочее время он скорее всего тоже не согласится. Причем чам выше зарплата этого разработчика тем более вероятно что он не согласится. Так вот есть в нашей области задачи, сложность которых аналогична мытью полов и является оскорбительной для достигнутого человеком профессионального уровня. И чем выше уровень — тем больше таких задач. Хотя у нас, конечно, люди как правило работы не боятся и сеньер девелоперы бодро носят мебель или коробки с чем попало, потому что у компании видимо нет денег на грузчиков.
Извиняюсь за пропитанный негативом к менеджменту текст. Но люди считающие других «ресурсами» несколько надоели своим отсутствием желания понимать область, в которой работают. Особенно ту часть области где оказывается что вокруг тоже люди, ничуть не хуже себя любимого.
1. Если у вас на компе работает, вполне возможно, что есть какой-то параметр, который пользователь не указал в багрепорте и его надо уточнить. Это если цель сделать качественное ПО, а не отказаться
2. Если у вас в разработке роль безмолвного исполнителя ТЗ бага, вероятно, прошла через приоретизацию при помощи того де человека, что и составлял т.з. соответственно, он уже учёл требования к пользователю — т.е. посчитал его неопытных а не мудаком.
3. Иногда полезно подумать, почему вообще бага возникла и как так больше не делать. Как такие баги находить быстрее? Не стоит ли тестерам сообщить — какие места лучше протестировать поподробнее и какие автоматические тесты лучше написать? Наше дело не искать виноватых, а вместе делать качественное ПО.
4. Согласен, правда я бы не тыкал, а задавал наводящих вопросы сначала — иногда есть какие-то обстоятельства, которых не знаешь.
5. На на доступном менеджеру языке обозначить причину задержки. Постараться разбить задачу на маленькие порции, чтобы говорить либо о 100% сделанной порции либо о несделанной. Поискать другие варианты или попросить коллегу покопаться вместе. В следующий раз перед оценкой отделить те куски, в которых ты не уверен и сообщить менеджеру. Сначала написать короткий прототип, в котором изучить сомнительные места jQuery. «Будет готово через 3 часа, если все пойдет гладко, но чтобы сказать точно надо сначала попробовать вот это — через полчаса скажу точнее».
6. Может быть ленивый разработчик, тупой менеджер или сочетание :).
7. Если предполагаемая «ерунда» не входит в обязанности разработчика, адекватный человек сообщит это другими словами не провоцируя конфликт.
2. Если у вас в разработке роль безмолвного исполнителя ТЗ бага, вероятно, прошла через приоретизацию при помощи того де человека, что и составлял т.з. соответственно, он уже учёл требования к пользователю — т.е. посчитал его неопытных а не мудаком.
3. Иногда полезно подумать, почему вообще бага возникла и как так больше не делать. Как такие баги находить быстрее? Не стоит ли тестерам сообщить — какие места лучше протестировать поподробнее и какие автоматические тесты лучше написать? Наше дело не искать виноватых, а вместе делать качественное ПО.
4. Согласен, правда я бы не тыкал, а задавал наводящих вопросы сначала — иногда есть какие-то обстоятельства, которых не знаешь.
5. На на доступном менеджеру языке обозначить причину задержки. Постараться разбить задачу на маленькие порции, чтобы говорить либо о 100% сделанной порции либо о несделанной. Поискать другие варианты или попросить коллегу покопаться вместе. В следующий раз перед оценкой отделить те куски, в которых ты не уверен и сообщить менеджеру. Сначала написать короткий прототип, в котором изучить сомнительные места jQuery. «Будет готово через 3 часа, если все пойдет гладко, но чтобы сказать точно надо сначала попробовать вот это — через полчаса скажу точнее».
6. Может быть ленивый разработчик, тупой менеджер или сочетание :).
7. Если предполагаемая «ерунда» не входит в обязанности разработчика, адекватный человек сообщит это другими словами не провоцируя конфликт.
Статья начинается с того, как хорошо что программисты уже не меняют картриджы, а являются специализированными разработчиками. Поэтому:
1. Параметры на компьютере пользователя — не проблема разработчика. Как и неправильно составленный баг-репорт. У нас же целый отдел обеспечения качества, который непонятно чем вообще занимаются!
2. Проблема разработчика — делать по ТЗ. А ТЗ — проблема аналитика. Если разработка выполнена по ТЗ — какие могут быть вопросы к разработчику?
3. Взаимодействие разработчика с тестером — хорошо. Позиционирование разработчика как «последний рубеж» единственно несущий ответственность за качество всей разработки — либо плохо либо признак ситуации когда разработчик один и он же и тестер и аналитик и архитектор. А над ним стоит только менеджер, который капает на мозг сроками.
5. Работа разработчика — разрабатывать. А вот работа менеджера — обеспечивать процесс. Менеджер должен знать язык разработчика, а не наоборот. Если разработчик знает язык менеджера — это очень хороший разработчик, который наверное сам скоро станет менеджером, потому что платят больше. Кстати именно от разбиения на порции рождается ответ «готово на 99%» :)
7. Слова, слова, я подозреваю что дело не в формулировке, а в сути. Если посыл будет мягким — он все-равно будет посылом и именно это не нравится автору. Да и опять же — разработчик не должен уметь общаться с людьми, он должен уметь разрабатывать. А менеджер должен уметь его понимать.
4. Вопрос вкуса, навеное. Когда мне начинают задавать наводящие вопросы и я догадываюсь что там косяк — мне кажется что со мной обращаются либо как с ребенком либо пытаются подтрунивать. Лучше сразу сказать — я считаю этот код плохим потому что. Если мне будет что ответить — я отвечу. И в споре родится истина. Если не будет — признаю свою неправоту и запомню как надо.
Но при этом есть очень обидчивые на прямое указание ошибки люди, которым как раз и надо задавать наводящие вопросы создавая эффект будто они сами нашли ошибку и более хороший путь решения. Тоже бывает, все мы разные.
1. Параметры на компьютере пользователя — не проблема разработчика. Как и неправильно составленный баг-репорт. У нас же целый отдел обеспечения качества, который непонятно чем вообще занимаются!
2. Проблема разработчика — делать по ТЗ. А ТЗ — проблема аналитика. Если разработка выполнена по ТЗ — какие могут быть вопросы к разработчику?
3. Взаимодействие разработчика с тестером — хорошо. Позиционирование разработчика как «последний рубеж» единственно несущий ответственность за качество всей разработки — либо плохо либо признак ситуации когда разработчик один и он же и тестер и аналитик и архитектор. А над ним стоит только менеджер, который капает на мозг сроками.
5. Работа разработчика — разрабатывать. А вот работа менеджера — обеспечивать процесс. Менеджер должен знать язык разработчика, а не наоборот. Если разработчик знает язык менеджера — это очень хороший разработчик, который наверное сам скоро станет менеджером, потому что платят больше. Кстати именно от разбиения на порции рождается ответ «готово на 99%» :)
7. Слова, слова, я подозреваю что дело не в формулировке, а в сути. Если посыл будет мягким — он все-равно будет посылом и именно это не нравится автору. Да и опять же — разработчик не должен уметь общаться с людьми, он должен уметь разрабатывать. А менеджер должен уметь его понимать.
4. Вопрос вкуса, навеное. Когда мне начинают задавать наводящие вопросы и я догадываюсь что там косяк — мне кажется что со мной обращаются либо как с ребенком либо пытаются подтрунивать. Лучше сразу сказать — я считаю этот код плохим потому что. Если мне будет что ответить — я отвечу. И в споре родится истина. Если не будет — признаю свою неправоту и запомню как надо.
Но при этом есть очень обидчивые на прямое указание ошибки люди, которым как раз и надо задавать наводящие вопросы создавая эффект будто они сами нашли ошибку и более хороший путь решения. Тоже бывает, все мы разные.
Интересно, что в каждом пункте вы пытаетесь доказать, что разработчик не виноват, а я пытаюсь показать, как должен действовать разработчик для выпуска более качественного продукта.
1. Если бага критическая и она воспроизводится только у клиента, то разработчик может помочь со своей стороны: добавить диагностику в код, посмотреть по коду вероятные причины и попробовать воспроизвести и т.д,
2 Опять поиск виноватого.Хороший разработчик может помочь улучшить ТЗ. Опять-таки, если ты бездумно вытачиваешь болванки по ТЗ не твое дело обсуждать интеллектуальные способности пользователя — для этого есть другие специальные люди.
3. Согласен, все несут ответственность. Не ищем виноватого, а делаем что можем, чтобы было лучше
5. Дело всех обеспечивать процесс со своей колокольни Если разработчик предпримет небольшие усилия, чтобы быть понятным окружающими, продукт будет лучшего качества, а разработчик более щедро оплачен.
7. Должен или не должен — зависит от конкретной ситуации, но это неинтересно. Интересно, как разработчик может стать лучше — общаться с коллегами приходится всегда и быть понятным коллегами разных уровней — весьма полезно.
4. Ну вопросы я практикую, когда уверен менее чем на 90% что косяк. Иначе можно просто высказывать в мягкой некатегоричной форме
1. Если бага критическая и она воспроизводится только у клиента, то разработчик может помочь со своей стороны: добавить диагностику в код, посмотреть по коду вероятные причины и попробовать воспроизвести и т.д,
2 Опять поиск виноватого.Хороший разработчик может помочь улучшить ТЗ. Опять-таки, если ты бездумно вытачиваешь болванки по ТЗ не твое дело обсуждать интеллектуальные способности пользователя — для этого есть другие специальные люди.
3. Согласен, все несут ответственность. Не ищем виноватого, а делаем что можем, чтобы было лучше
5. Дело всех обеспечивать процесс со своей колокольни Если разработчик предпримет небольшие усилия, чтобы быть понятным окружающими, продукт будет лучшего качества, а разработчик более щедро оплачен.
7. Должен или не должен — зависит от конкретной ситуации, но это неинтересно. Интересно, как разработчик может стать лучше — общаться с коллегами приходится всегда и быть понятным коллегами разных уровней — весьма полезно.
4. Ну вопросы я практикую, когда уверен менее чем на 90% что косяк. Иначе можно просто высказывать в мягкой некатегоричной форме
Этому есть простое объяснение — статья обязывает разработчика к чему-то. А разработчик действительно не виноват. Я согласен с тем что он может — он может и дебаггинг на стороне клиента сделать, и ТЗ улучшить и тестирование провести и научиться с людьми общаться. Но ведь еще он может поменять картридж в принтере, может поуправлять проектом, поносить коробки с этажа на этаж. Он все это может, но не должен как пытается убедить нас автор статьи.
Разделение труда такая штука когда каждый делает наилучшим образом именно свой участок работы и не лезет в другие. Есть человек ответственный за ТЗ? Пусть он составляет ТЗ, не отбирай у него хлеб, это не пойдет на пользу ни ему, ни тебе ни ТЗ. Есть процесс баг-трекинга? Не влезай мимо него в исправление багов, иначе ты рискуешь сделать лишнюю, не нужную и не оплаченную работу которая к тому же не будет учтена в будущем планировании менеджментом и в реализации аналогичной фичи реализатором, а так же не будет проверена тестировщиком.
Своими действиями на чужом поле мимо процедур ты не просто получаешь дополнительный опыт в смежных областях, ты отнимаешь его у других и одновременно рушишь стройную производственную систему. К сожалению даже сами управляющие зачастую этого не понимают и являются инициаторами такого разрушения. А потом удивляются что бардак, что никакая система не работает значит все эти системы отстой, мы придумаем свою — все делают всё и работают в поте лица на общее благо как только могут.
Разделение труда такая штука когда каждый делает наилучшим образом именно свой участок работы и не лезет в другие. Есть человек ответственный за ТЗ? Пусть он составляет ТЗ, не отбирай у него хлеб, это не пойдет на пользу ни ему, ни тебе ни ТЗ. Есть процесс баг-трекинга? Не влезай мимо него в исправление багов, иначе ты рискуешь сделать лишнюю, не нужную и не оплаченную работу которая к тому же не будет учтена в будущем планировании менеджментом и в реализации аналогичной фичи реализатором, а так же не будет проверена тестировщиком.
Своими действиями на чужом поле мимо процедур ты не просто получаешь дополнительный опыт в смежных областях, ты отнимаешь его у других и одновременно рушишь стройную производственную систему. К сожалению даже сами управляющие зачастую этого не понимают и являются инициаторами такого разрушения. А потом удивляются что бардак, что никакая система не работает значит все эти системы отстой, мы придумаем свою — все делают всё и работают в поте лица на общее благо как только могут.
я совершенно согласен с такой постановкой вопроса. Но во-первых, я говорю не о взятии полностью ответственности за чужой участок работы, а о посильный помощи — человек написал непонятное или противоречивые ТЗ — обрати внимание, человек написал избыточно подробно — подскажи как сэкономить время. То есть области ответственности долины иметь перекрытие — так как мы имеем дело с людьми, а не с кирпичом то если перекрытий не будет — будут пустые пространства и качество пострадает. В случае с багтрекингом рассматриваем задачу когда бага уде пришла к тебе с просьбой исследовать возможные причины и дать рекомендации по воспроизведению, например. Или можешь сам предложить, но дело менеджера — решить надо так помогать QA или нет. Ты не отнимаешь опыт у других, а делиться им — от взаимодействия с разработчиком постановщик лучше поймет как составить ТЗ более логично. Тестеры будут знать, что можно не только тупо перебирать варианты, но и попросить разработчика добавить диагностику или научатся анализировать крешдампы.
Все работают на общее благо как могут, но дело каждого знать — где он принимает решение, а где он моет использовать возможность совещательного голоса.
Еще по поводу разделения труда — вот такой пример — почему нету специального человека для завязывания шнурков — он будет все делать быстрее и качественнее?
Вы читали книжки от 37signals?
Все работают на общее благо как могут, но дело каждого знать — где он принимает решение, а где он моет использовать возможность совещательного голоса.
Еще по поводу разделения труда — вот такой пример — почему нету специального человека для завязывания шнурков — он будет все делать быстрее и качественнее?
Вы читали книжки от 37signals?
Нет, не читал.
Вцелом я согласен с выраженной мыслью. Тем более что она не сходится с выраженным в статье, а претензии у меня именно к статье.
А вот человек для завязывания шнурков рано или поздно появится. Либо этот процесс будет автоматизирован/упразднен. Доказательств у меня аж два.
Первое теоретическое: когда-то один человек и убивал мамонта, и свежевал его, и резал, и готовил, и ел. А теперь цепочка людей от выращивающего животных до поедающего мясо состоит из нескольких десятков разных профессий. И представитель одной зачастую даже не представляет себя в роли представителя другой. То что сейчас нам кажется очевидным и элементарным, тем что должен уметь каждый человек через сотню другую лет может быть уже совсем иначе. Ведь пару сотен лет назад каждый уважающий себя джентельмен был обязан уметь фехтовать и стрелять, а сейчас этим занимаются либо спортсмены, либо бандиты либо милиция либо армия. Ну либо любители, в порядке хобби.
Ах да, второе практическое. Я не умел завязывать шнурки где-то до 10-11 лет. То-есть у меня получалось, но плохо, поэтому мне их обычно завязывала мама. При этом я был первым учеником в классе, я читал и писал с первого класса лучше других, знал математику, легко все запоминал. Голова работала отлично, а мелкая моторика рук не очень. Когда появится нейроинтерфейс для управления компьютером — дай бог чтобы программисты вообще ходить не разучились и за них этого не делали «узкие специалисты».
Кстати пока писал подумал… А ведь такой человек есть! Только вместо того чтобы завязывать другим шнурки он оптимизировал процесс: молнии, липучки, резинки. Обувь без шнурков — это и есть результат работы специального человека по завязыванию шнурков. И кто скажет что он справился со своей работой не быстрее и качественнее обывателя?
Вцелом я согласен с выраженной мыслью. Тем более что она не сходится с выраженным в статье, а претензии у меня именно к статье.
А вот человек для завязывания шнурков рано или поздно появится. Либо этот процесс будет автоматизирован/упразднен. Доказательств у меня аж два.
Первое теоретическое: когда-то один человек и убивал мамонта, и свежевал его, и резал, и готовил, и ел. А теперь цепочка людей от выращивающего животных до поедающего мясо состоит из нескольких десятков разных профессий. И представитель одной зачастую даже не представляет себя в роли представителя другой. То что сейчас нам кажется очевидным и элементарным, тем что должен уметь каждый человек через сотню другую лет может быть уже совсем иначе. Ведь пару сотен лет назад каждый уважающий себя джентельмен был обязан уметь фехтовать и стрелять, а сейчас этим занимаются либо спортсмены, либо бандиты либо милиция либо армия. Ну либо любители, в порядке хобби.
Ах да, второе практическое. Я не умел завязывать шнурки где-то до 10-11 лет. То-есть у меня получалось, но плохо, поэтому мне их обычно завязывала мама. При этом я был первым учеником в классе, я читал и писал с первого класса лучше других, знал математику, легко все запоминал. Голова работала отлично, а мелкая моторика рук не очень. Когда появится нейроинтерфейс для управления компьютером — дай бог чтобы программисты вообще ходить не разучились и за них этого не делали «узкие специалисты».
Кстати пока писал подумал… А ведь такой человек есть! Только вместо того чтобы завязывать другим шнурки он оптимизировал процесс: молнии, липучки, резинки. Обувь без шнурков — это и есть результат работы специального человека по завязыванию шнурков. И кто скажет что он справился со своей работой не быстрее и качественнее обывателя?
> 001. А у меня на компе работает
Нормальная фраза, как начало диалога. Я после этого обычно начинаю искать различия в dev и test среде, совместно с QA. Еще варианты — удаленная отладка, запись логов/дампов, удаленный доступ.
> Запомни раз и навсегда, что тестеры не отвечают за качество ПО.
До меня уже высказались — не ясно зачем тогда уже нужны тестеры. У разработчика в большинстве случаев тестирование это юнит-тесты, нагрузочные тесты, возможно UI тесты. Если он будет прогонять все варианты, на всех платформах, браузерах итд вы такие сроки получите… Кроме того опять же — иногда QA находят в моем коде такие повороты, которые я бы сам искал долго. Именно из-за юзероского подхода (а что если нажать две кноки сразу итд).
> 100. Какой идиот это писал?
Вот тут согласен — плевать в коллег не хорошо. Лучше лично разрулять (за редкими исключениями, которых я к счастью не встчерал).
> Меня не очень интересуют интимные подробности
Кстати, при фиксе багов в том году пару раз попадал в такую ситуацию, когда не понимаешь сути (FF порадовал) и сложно оценить время на решение.
С другой стороны, согласен с другими, кто написал что надо правльно ставить вопрос.
> 110. Это невозможно!
Как правило в этой фразе есть недоговоренность «в эти сроки, за эти деньги, с такой командой». Можешь тыкать сколько угодно FAT-ом, но Azure за ночь в одиночку с нуля не склонировать. Как и Win не написать. Будешь спорить?
PS: честно говоря жалко твоих разработчиков, если конечно только у них не такая огромная ЗП и такие интересные проекты чтобы тянуть все, включая QA.
Нормальная фраза, как начало диалога. Я после этого обычно начинаю искать различия в dev и test среде, совместно с QA. Еще варианты — удаленная отладка, запись логов/дампов, удаленный доступ.
> Запомни раз и навсегда, что тестеры не отвечают за качество ПО.
До меня уже высказались — не ясно зачем тогда уже нужны тестеры. У разработчика в большинстве случаев тестирование это юнит-тесты, нагрузочные тесты, возможно UI тесты. Если он будет прогонять все варианты, на всех платформах, браузерах итд вы такие сроки получите… Кроме того опять же — иногда QA находят в моем коде такие повороты, которые я бы сам искал долго. Именно из-за юзероского подхода (а что если нажать две кноки сразу итд).
> 100. Какой идиот это писал?
Вот тут согласен — плевать в коллег не хорошо. Лучше лично разрулять (за редкими исключениями, которых я к счастью не встчерал).
> Меня не очень интересуют интимные подробности
Кстати, при фиксе багов в том году пару раз попадал в такую ситуацию, когда не понимаешь сути (FF порадовал) и сложно оценить время на решение.
С другой стороны, согласен с другими, кто написал что надо правльно ставить вопрос.
> 110. Это невозможно!
Как правило в этой фразе есть недоговоренность «в эти сроки, за эти деньги, с такой командой». Можешь тыкать сколько угодно FAT-ом, но Azure за ночь в одиночку с нуля не склонировать. Как и Win не написать. Будешь спорить?
PS: честно говоря жалко твоих разработчиков, если конечно только у них не такая огромная ЗП и такие интересные проекты чтобы тянуть все, включая QA.
Считаю, что это ценная статья.
Но, её ценность совсем не в «правильности утверждений и выводов», а в том, что эта статья хорошо демонстрирует мировоззрение большой части отечественных разработчиков.
Мой личный опыт НЕ позволяет мне согласиться с большинством(!) утверждений и выводов из этой статьи. И, предполагаю, что мои аргументированные возражения по всем таким пунктам превысят объем самой статьи.
IMHO Не эффективно делать такое в этом комментарии. Тем более, что мои возражения просто будут выражать другую субъективную\мою точку зрения по каждому пункту статьи. И в идеале нужен будет арбитраж по альтернативным мнениям для установления «истины», но принципы демократии принятые Хабре не помогут нам в этом. («большинством голосов установить удобное нам значение числа Пи»).
Поэтому, я избрал другой путь…
Я попытался разобраться почему у меня эта статья вызывает диссонанс и, похоже, нашел ответ:
Существуют различия в культуре производства программного обеспечения в различных компаниях.
Именно эти различия и определяют наше отношение к шаблонам проектирования, процессам разработки и выпуска ПО, к QA процессам и специалистам, и, в конце концов, к самоопределению «разработчика»\«программиста»\«оператора ЭВМ» во всех этих процессах.
Но, её ценность совсем не в «правильности утверждений и выводов», а в том, что эта статья хорошо демонстрирует мировоззрение большой части отечественных разработчиков.
Мой личный опыт НЕ позволяет мне согласиться с большинством(!) утверждений и выводов из этой статьи. И, предполагаю, что мои аргументированные возражения по всем таким пунктам превысят объем самой статьи.
IMHO Не эффективно делать такое в этом комментарии. Тем более, что мои возражения просто будут выражать другую субъективную\мою точку зрения по каждому пункту статьи. И в идеале нужен будет арбитраж по альтернативным мнениям для установления «истины», но принципы демократии принятые Хабре не помогут нам в этом. («большинством голосов установить удобное нам значение числа Пи»).
Поэтому, я избрал другой путь…
Я попытался разобраться почему у меня эта статья вызывает диссонанс и, похоже, нашел ответ:
Существуют различия в культуре производства программного обеспечения в различных компаниях.
Именно эти различия и определяют наше отношение к шаблонам проектирования, процессам разработки и выпуска ПО, к QA процессам и специалистам, и, в конце концов, к самоопределению «разработчика»\«программиста»\«оператора ЭВМ» во всех этих процессах.
Это невозможно!
Хочется прокомментировать эту фразу. Зачастую, если программист её произносит, это значит, что он не мотивирован решать задачу. Вопрос — почему? Причин может быть множество, но наиболее вероятная — программиста не привлекали к её обсуждению. Менеджеры где-то там у себя посовещались и просто выдали программисту готовое задание, даже не поинтересовавшись, что он думает по этому поводу. А он, между прочим, не просто технарь-обслуга, как робот выполняющий любые капризы менеджеров, а ответственное лицо. У которого есть и сроки, и представление чего будет стоить внедрение такой-то фичи.
Эта фраза — естественная реакция программиста на задачу, которая сваливается на него как снег на голову и насчёт которой ему понятно, что за него уже всё решили, делай-делай, не отвлекайся.
Часть пунктов являются, как минимум спорными, на что неоднократно указали в комментариях.
Часть — очередное изложение превосходной классической книги «The Progmatic Programmer» (Andrew Hunt & David Thomas). Даже, если автор не читал эту книгу, то многие утверждения из неё на хабре появлялись далеко не единожды.
В общем, мне этот пост видится пафосной жижицей.
Часть — очередное изложение превосходной классической книги «The Progmatic Programmer» (Andrew Hunt & David Thomas). Даже, если автор не читал эту книгу, то многие утверждения из неё на хабре появлялись далеко не единожды.
В общем, мне этот пост видится пафосной жижицей.
Автор молодец! Не смотри на рейтинг, покуда карма позволяет — пиши! :) С новым годом!
А чё «001. А у меня на компе работает!»?
Чё не «000»?
Чё не «000»?
Как много раз упоминается «Чувак»…
Если я проавильно загуглил, то автор статьи работает в фирме knoema.com/
Открыв сайт я увидел текст:
Your browser is not supported.
The browser you are currently using is not supported by knoema.com. Portions of our website may not display or function properly when used with your current browser. We recommend using a most recent version of one of these supported browsers when visiting knoema.com.
Если я правильно понял, то ответ автора статьи должен быть «001. А у меня на компе работает».
Открыв сайт я увидел текст:
Your browser is not supported.
The browser you are currently using is not supported by knoema.com. Portions of our website may not display or function properly when used with your current browser. We recommend using a most recent version of one of these supported browsers when visiting knoema.com.
Если я правильно понял, то ответ автора статьи должен быть «001. А у меня на компе работает».
А какой браузер не поддерживают? Просто интересно.
Opera 12
Нда… Проверил — так и есть. Ну это уже смешно тогда (если вы не ошиблись с фирмой). Забить на один из современных браузеров (я думал вдруг речь про IE6 или FF3 :) )… Видимо и правда главное что у автора «на компе работает». :)
Да, да. А еще в Америке негров линчуют…
По существу сказать нечего, но ответить очень хотелось?
Я не фанат Opera. Но как web разрабочик считаю что страница «ваш браузер не поддерживается» допустима только в 2 случаях:
— для старых браузеров типа упомянутых IE6, FF3.
— если для веб-приложения жизненно необходима поддержка фич(и), которые есть только в конкретных браузерах (как правило приложения, суть и ядро которых базируется самых новых фичах).
в остальных — это как признание в собственной проф. непригодности.
Я не фанат Opera. Но как web разрабочик считаю что страница «ваш браузер не поддерживается» допустима только в 2 случаях:
— для старых браузеров типа упомянутых IE6, FF3.
— если для веб-приложения жизненно необходима поддержка фич(и), которые есть только в конкретных браузерах (как правило приложения, суть и ядро которых базируется самых новых фичах).
в остальных — это как признание в собственной проф. непригодности.
Ваше право считать, что угодно. Какое отношение отсутствие поддержки Оперы 12 имеет к теме данной статьи? Вам надо меня уязвить любой ценой? Могу Вам сразу список баг выкатить.
Бедняжки, уже перешли на личность автора, дабы обосрать его мнение. Погуглите соцсети еще, может семью найдете, и там не понравится что жена ходит в зеленой кофте и обгадьте её вкус, ведь вам нравится желтый! Вам же это доставляет удовольствие, как я понял. Тьфу, стыдно… Не понравилось мнение, так идите лесом да не читайте, разве это так сложно. Читать комменты даже невозможно из-за этого мусора, и мне уже вон, уподобится вам пришлось.
Наверное это потому, что автор не писал тут, как должна выглядеть жена. Но зато говорит о том, что и как должно работать у девелопера.
> Но зато говорит о том, что и как должно работать у девелопера
Это лишь его взгляд, не более. Не нужно из статьи делать аксиому и всячески пытаться доказать, что это не аксиома :). Я бы тоже со многими пунктами не согласился, но это же не означает, что нужно поливать человека грязью и тем более искать «обходные» пути для этого.
Это лишь его взгляд, не более. Не нужно из статьи делать аксиому и всячески пытаться доказать, что это не аксиома :). Я бы тоже со многими пунктами не согласился, но это же не означает, что нужно поливать человека грязью и тем более искать «обходные» пути для этого.
ie11, причем рекомендует скачать его же
В 12 Опере есть баг с JS, который ломает стандартный, обфусцированный jQuery. Баг признан разработчиками Оперы и исправлен в 12.5 если не ошибаюсь и эту версию мы поддерживаем. Пользователей, заходящих с 12 Оперы у нас меньше сотой доли процента. Ничего личного, только бизнес.
«Меня не очень интересуют интимные подробности твоих непростых взаимоотношений с очередным плагином к jQuery. И уж тем более не надо мне говорить про 99%.» © сами знаете кто
И причем здесь это? Осознанное решение. Цитата «Пользователей, заходящих с 12 Оперы у нас меньше сотой доли процента. Ничего личного, только бизнес.»
А зачем вы делитесь с нами «подробностями непростых взаимоотношений» (в 12 не пашет, но 12.5 поддержим)? Не смогли обойти баг? Просто бы написали что это не возможно… упс… :)
Андрей,
Повторюсь еще раз. Цитата «Пользователей, заходящих с 12 Оперы у нас меньше сотой доли процента. Ничего личного, только бизнес.»
Повторюсь еще раз. Цитата «Пользователей, заходящих с 12 Оперы у нас меньше сотой доли процента. Ничего личного, только бизнес.»
Так может их так мало из-за того, что у них ваш сайт не работает?
Возможно, хотя и не в этом дело. Но это наш сайт и мы решаем какие браузеры поддерживать, а какие нет. С IE 6-7 ходят в разы больше пользователей и мы им тоже предлагаем обновиться. Если Вас лично это не устраивает могу только принести извинения и предложить воспользоваться другим, устраивающим вас сервисом.
Владимир,
Намекну еще раз на двойные стандарты. Почему-то разработчик должен делать все и вся по первому требованию, а вы можете послать пользователя нафиг?
Кроме того,
— согласен с комментом habrahabr.ru/post/208170/#comment_7170524
— мое личное мнение про страницы «не поддерживаем» вы уже знаете. (для остальных читающих — это в подавляющем случае не профессионально)
Намекну еще раз на двойные стандарты. Почему-то разработчик должен делать все и вся по первому требованию, а вы можете послать пользователя нафиг?
Кроме того,
— согласен с комментом habrahabr.ru/post/208170/#comment_7170524
— мое личное мнение про страницы «не поддерживаем» вы уже знаете. (для остальных читающих — это в подавляющем случае не профессионально)
Разработчику я плачу зарплату, высокую. Он наемный работник. Пользователь волен пользоваться сервисом, либо нет. Пользователей, платящих нам деньги, мы вылизываем и никогда не пошлем нафиг. Заплатите нам за годовую подписку я и Вас буду вылизывать.
Когда вам нужны не девелоперы, а кодеры. Кто будет по ТЗ просто кодить 1 в 1 без вопросов. Только ТЗ давайте максимально точно, ибо додумывать они не будут.
Да, если девелопер говорит, что что-то невозможно, то он должен пояснить почему и что мешает. Ну или уточните сами (и научите его пояснять в следующий раз самому). Попробуйте строить диалог, т.к. профессионалы сами заинтересованы в результате.
Кроме того, я уже говорил, что «невозможно» как правило идет в контексте команды/сроков/оплаты. Пусть у вас высокие ЗП, но это не значит что люди должны сидеть 24 часа в сутки в рабстве, закрывая очередную «хотелку».
Ну и небольшое IMHO, вам стоит не делить пользователей на платящих и остальных (без права голоса). Это только усложняет конвертацию вторых в первых.
Да, если девелопер говорит, что что-то невозможно, то он должен пояснить почему и что мешает. Ну или уточните сами (и научите его пояснять в следующий раз самому). Попробуйте строить диалог, т.к. профессионалы сами заинтересованы в результате.
Кроме того, я уже говорил, что «невозможно» как правило идет в контексте команды/сроков/оплаты. Пусть у вас высокие ЗП, но это не значит что люди должны сидеть 24 часа в сутки в рабстве, закрывая очередную «хотелку».
Ну и небольшое IMHO, вам стоит не делить пользователей на платящих и остальных (без права голоса). Это только усложняет конвертацию вторых в первых.
Если разработчик не исполняет обязанности менеджера, не его дело выбирать, какие возможности нужны пользователю, а какие нет, так как он не видит картины в целом и value с точки зрения бизнеса. У него совещательный голос. Мне кажется во всех методология так. У него своя область ответственности относящаяся к реализации хотелок, а не их приоритета. Иначе он должен предоставлять экономическое обоснование
Дело разработчика не выбирать что нужно пользователю, а что нет. Его дело оценить возможность создания заданного функционала или внесения заданных изменений в заданные сроки. А так же воздействие от такого внесения (ведь иногда можно сделать костыль на скорую руку и радость менеджера, но потом разгребать в 100 раз больше из-за этого).
И видел и когда то сам писал костыльные проекты. Сейчас я предпочту искать компромисс в таком случае, т.к. где один костыль, там и второй. А в один момент костыли начинают ломаться. Догадаетесь что в итоге?
И что лучше: иметь дело с человеком который соглашается со всем, но срывает сроки, ибо взял сильно много, или человеком которые мотивированно откажет и предложит попробовать найти варианты решения. Да, на первого можно повесить всех собак (это он всех подвел), но толку? Клиенту кто именно лажанул без разницы, для него лажанула сама контора.
И видел и когда то сам писал костыльные проекты. Сейчас я предпочту искать компромисс в таком случае, т.к. где один костыль, там и второй. А в один момент костыли начинают ломаться. Догадаетесь что в итоге?
И что лучше: иметь дело с человеком который соглашается со всем, но срывает сроки, ибо взял сильно много, или человеком которые мотивированно откажет и предложит попробовать найти варианты решения. Да, на первого можно повесить всех собак (это он всех подвел), но толку? Клиенту кто именно лажанул без разницы, для него лажанула сама контора.
См в исходном тексте:
«Вместо того, чтобы сказать «Это невозможно!» необходимо просто взять паузу, подумать, остыть, а затем сесть со своим тимлидом или руководителем и проговорить проблему. „
Таким образом никто не говорит, что разработчик бессловесная тварь, которая не может вообще ничего сказать. Но последнее слово за менеджером, так как он представляет интересы клиента.
«Вместо того, чтобы сказать «Это невозможно!» необходимо просто взять паузу, подумать, остыть, а затем сесть со своим тимлидом или руководителем и проговорить проблему. „
Таким образом никто не говорит, что разработчик бессловесная тварь, которая не может вообще ничего сказать. Но последнее слово за менеджером, так как он представляет интересы клиента.
Ок, задача «написать Azure к утру». Будем обсуждать или «это невозможно»?
Уже не знаю почему, может из-за стиля изложения у меня именно такое ощущение о стиле руководства автора.
Уже не знаю почему, может из-за стиля изложения у меня именно такое ощущение о стиле руководства автора.
Обсуждать, конечно — может выясниться, что не Azure и не к утру и не написать, а купить.
И как вы будете кастомизировать и перепродавать купленный акк. в Azure :) Не все задачи выполнимы (с учетом цены и сроков).
Дык от пациента требуется информированное согласие — объясняем что возможно, а не говорим, что невозможно. А ажур кастомизируется положениями под него
Я про кастомизацию самого ядра, а не создание приложений. В общем ушли в сторону от сути топика.
Нормально сказать «это невозможно» только за этим должно следовать уточнение что именно надо сделать почему и какие возможны компромиссы. То есть зачем именно вдруг azure, именно свой и к утру? Смоделируйте ситуацию с начала — откуда в голове начальника появилась эта идея, что ему нужно на самом деле, а то получается сферический амур в вакууме.
Вы о чем вообще?
Opera 12.5??
А такая есть???
Вы поддерживаете версию Оперы которой не существует????
На официальном сайте предлагают скачать или Хроперу 18 или Оперу 12.16
У меня же 12.16 как раз и стоит.
Opera 12.5??
А такая есть???
Вы поддерживаете версию Оперы которой не существует????
На официальном сайте предлагают скачать или Хроперу 18 или Оперу 12.16
У меня же 12.16 как раз и стоит.
Так. Странно. Opera 12.50 действительно существует, но на официальном сайте почему то ее не предлагают скачать. И при попытке обновить оперу пишет что у меня 12.16 последняя.
Она была, называлась Opera Next еще пока не было принято решение о радикальной смене движка. Вам дистрибутив дать?
Жалко разработчиков, которые работаю с автором. Особенно исходя из пункта 101.
На самом деле работать под руководством vbougay очень комфортно. Я вас уверяю, что более адекватного начальника сложно найти:)
Спасибо за интересную статью.
По заголовку
сразу вспомнил про Словарь ненормативной лексики программиста от Ашманова. Не читали? У Вас получилось неплохое дополнение.
По заголовку
001. А у меня на компе работает
сразу вспомнил про Словарь ненормативной лексики программиста от Ашманова. Не читали? У Вас получилось неплохое дополнение.
Мы все очень любим (или не любим) поговорить о шаблонах проектирования. Лично я их сильно недолюбливаю, т.к. большинство из них достаточно очевидны для более или менее опытного разработчика, а шаблонность мышления еще никому в жизни не помогала.
Шаблоны это не только примеры удачных архитектурных решений, не менее важно то, что шаблоны дают единый словарь терминов, которые можно использовать в дискуссиях и пояснениях к коду. Т.о. вместо того, чтобы каждый раз объяснять что вы спроектировали вы просто говорите это Фабрика, Медиатор,…
У вас тут что, тоже Майдан? Вполне разумные вещи автор толкует, зачем заминусовали?
В комментариях всё написано. Или вы, их не читая, решили просто набросить?
В статье всё таки попытка донести позицию «с той стороны барикад», комменты — это уже отдельная история. Я знаю как мы любим слушать себя, но увидеть ситуацию с другой стороны никому ещё не повредило.
del
Мне кажется, что позиция, высказанная в статье очень утрированная и максималисткая. По моему мнению (хотя возможно автор этого не подразумевал), налицо недостаточная степень коммуникации и понимания между менеджером и разработчиком. С другой стороны, любая описанная проблема имеет много граней, что уже отмечено в других комментариях.
001. А у меня на компе работает
Здесь нужно понимать, в каком качестве вы рассматриваете разработчика, насколько узко он специализирован, есть ли у вас QA, саппорт и прочее-прочее. Нельзя объять необъятное. Такой ответ плох, если разработчик просто не хочет с этим разбираться. Но, если в этом могут разобраться саппорт и прочие — то почему этим должен заниматься разработчик? Я, можно сказать, ежедневно встречаюсь с этой ситуацией, причем лично. Так вот, у нас не принято при этом винить в этом разработчика. И, да, у него действительно это работает. Решение: предоставить информацию о проблеме, среду для воспроизведения — от этого разработчику будет трудно уже уйти, т.к. есть конкретная задача, конкретные данные.
010. Какой мудакпользователь так (с)делает?
У любого ПО есть свои ограничения. И не разработчик, а люди над ним, должны решать какие ограничения будут включены в продукт, а какие нет. Потому что, в общем случае, ограничений бесконечное множество, о многих вы не сможете догадаться. Если разработчик считает ограничение бессмысленным, то нужно объяснить ему логику ограничения. Иначе получается «я — начальник, поэтому будешь делать, как я хочу», что есть неправильно. Решение: описать все ограничения, которые вы поддерживаете, по каждому, разработчику и/или тестеру ставится конкретная задача. Если пользователь обходит какое-то ограничение, то опять же, не разработчик, а люди над ним решают поддерживаем ли мы это ограничение или нет. Да и еще, непредусмотренные ограничение, не обнаруженные ни разработчиком, ни тестером, ни сотней пользователь за первые 5 лет пользования, обязательно вылезут.
011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
По-хорошему, разработчики и тестеры должны быть одной командой. Если разработчики противопоставляют себя тестерам — это уже плохой знак. Если не идут на контакт — тоже плохо. И задача руководителя наладить этот контакт, чтобы о том, что Вася не разговаривает с Петей было известно заранее, а не тогда, когда пришел баг, а они не могут друг к другу подойти. Опять же, разработчики и тестеры должны друг другу рассказывать, что они накодили или натестили.
100. Какой идиот это писал?
Тоже знакомая ситуация, да, иногда натыкаешься на плохой код. И да, иногда, ты сам это написал. Но, постойте, так есть же решение: код ревью. Только «пообщайся с челом» — это, извините, было актуально 10 лет назад, а в дополнение к код ревью — самое то. Да и рефакторинг никто не отменял. Опять же, возможно, здесь подразумевается, что проблема в том, что разработчик не хочет иметь дело с чужим кодом. Но эта проблема психологическая (а, значит, зона ответственности руководителя). Если код действительно идиотский — то и руководитель должен понимать, что его лучше переписать, что улучшит его поддержку в будущем. Если разработчик просто не может понять, что в коде происходит — то это уже совсем другая проблема. Если сам разработчик некомпетентен, то нужно найти более опытного (если возможно). Если действительно код запутанный, то опять же рефакторинг. Если… (впрочем, здесь еще много «если» может быть).
101. Готово на 99%
Про будущее здесь уже написали. Про эстимейты тоже. Я не знаю про конкретную ситуацию в каждой компании, поэтому опишу, как подходят к этой проблеме в части из них. Эстимейт — это всегда оценка, он всегда должен подразумевать оптимистическую и пессимистическую оценку. По-хорошему, должны быть указаны риски (а вдруг в другой среде всё будет не так, а вдруг, мы не сможем найти решение за указанное время, и т.п.). А руководитель уже должен руководствоваться как эстимейтом, так и рисками (которые объясняют, почему мы можем пойти по пессимистической оценке). Немного странно, что статус задачи подразумевает сроки. Сроки нужно обсуждать до начала задачи. А во время спрашивать уже о статусе. Впрочем, здесь может быть длинная дискуссия, об этом написано немало книг. Опять же, по-хорошему, в эстимейт должен входить не только сам кодинг, но и исследование, и отладка, и тестирование. Всё это должен понимать и руководитель, и разработчик еще на этапе эстимейта и оценивания рисков. Также замечу, что руководитель чутьем или опытом, должен понимать адекватны ли эстимейты и риски, и обсудить это до начала задачи. Если вы начинаете работать с плагином, с которым вы никогда не встречались, если он плохо задокументирован, если… — это риск, его нужно оценить до начала задачи. Это проблема не только разработчика, но и самого руководителя. Его должны интересовать непростые отношения с этим плагином, потому что он должен понимать, сделает ли данный разработчик эту задачу или нет. Например, если есть разработчик А (знакомый с другими плагинами) и разработчик Б (не знакомый), но разработчик А занят на других задачах, то неадекватно полагать, что разработчик Б сделает ту же задачу за то же время, только потому что руководитель так хочет.
110. Это невозможно!
Здесь уже описали действительно невозможные задачи. В каком-то смысле, этот пункт тесно завязан с предыдущим. Да и непонятно, невозможно ли вообще, или невозможно за отведенное время. Если разработчик четко указывает почему невозможно — то всё обсуждаемо.
111. Я такую ерунду делать не буду.
Да, в принципе, всё просто — или делай, или увольняйся. Но, с другой стороны, это максимализм. Из собственного опыта — если ты умеешь объяснить рациональность мотивов, что стоит за задачей и зачем она нужна — разработчик может поменять мнение или согласиться, что это необходимо.
В общем говоря, все указанные пункты, высказанные в ключе «Я начальник, поэтому разработчик будет делать, как я говорю» естественно вызвали негативную реакцию. По крайней мере, я вижу, что многие именно так и поняли данную статью. Если автор этого не подразумевал — то дело другое, но, что написано, то написано. Все проблемы вполне решаемы, где-то виновата лень, где-то отрицание (гнев, торг, депрессия), но ведь задача именно руководителя мотивировать разработчика делать работу. Люди все где-то немножко ленивы, где-то безответственны, где-то капризные. Но ведь вы их почему-то приняли на работу, а, возможно, уже проработали несколько лет. Значит, есть у них плюсы — и задача руководителя заставить эти «плюсы» работать. Ведь вы же одна команда, не так ли?
001. А у меня на компе работает
Здесь нужно понимать, в каком качестве вы рассматриваете разработчика, насколько узко он специализирован, есть ли у вас QA, саппорт и прочее-прочее. Нельзя объять необъятное. Такой ответ плох, если разработчик просто не хочет с этим разбираться. Но, если в этом могут разобраться саппорт и прочие — то почему этим должен заниматься разработчик? Я, можно сказать, ежедневно встречаюсь с этой ситуацией, причем лично. Так вот, у нас не принято при этом винить в этом разработчика. И, да, у него действительно это работает. Решение: предоставить информацию о проблеме, среду для воспроизведения — от этого разработчику будет трудно уже уйти, т.к. есть конкретная задача, конкретные данные.
010. Какой мудакпользователь так (с)делает?
У любого ПО есть свои ограничения. И не разработчик, а люди над ним, должны решать какие ограничения будут включены в продукт, а какие нет. Потому что, в общем случае, ограничений бесконечное множество, о многих вы не сможете догадаться. Если разработчик считает ограничение бессмысленным, то нужно объяснить ему логику ограничения. Иначе получается «я — начальник, поэтому будешь делать, как я хочу», что есть неправильно. Решение: описать все ограничения, которые вы поддерживаете, по каждому, разработчику и/или тестеру ставится конкретная задача. Если пользователь обходит какое-то ограничение, то опять же, не разработчик, а люди над ним решают поддерживаем ли мы это ограничение или нет. Да и еще, непредусмотренные ограничение, не обнаруженные ни разработчиком, ни тестером, ни сотней пользователь за первые 5 лет пользования, обязательно вылезут.
011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
По-хорошему, разработчики и тестеры должны быть одной командой. Если разработчики противопоставляют себя тестерам — это уже плохой знак. Если не идут на контакт — тоже плохо. И задача руководителя наладить этот контакт, чтобы о том, что Вася не разговаривает с Петей было известно заранее, а не тогда, когда пришел баг, а они не могут друг к другу подойти. Опять же, разработчики и тестеры должны друг другу рассказывать, что они накодили или натестили.
100. Какой идиот это писал?
Тоже знакомая ситуация, да, иногда натыкаешься на плохой код. И да, иногда, ты сам это написал. Но, постойте, так есть же решение: код ревью. Только «пообщайся с челом» — это, извините, было актуально 10 лет назад, а в дополнение к код ревью — самое то. Да и рефакторинг никто не отменял. Опять же, возможно, здесь подразумевается, что проблема в том, что разработчик не хочет иметь дело с чужим кодом. Но эта проблема психологическая (а, значит, зона ответственности руководителя). Если код действительно идиотский — то и руководитель должен понимать, что его лучше переписать, что улучшит его поддержку в будущем. Если разработчик просто не может понять, что в коде происходит — то это уже совсем другая проблема. Если сам разработчик некомпетентен, то нужно найти более опытного (если возможно). Если действительно код запутанный, то опять же рефакторинг. Если… (впрочем, здесь еще много «если» может быть).
101. Готово на 99%
Про будущее здесь уже написали. Про эстимейты тоже. Я не знаю про конкретную ситуацию в каждой компании, поэтому опишу, как подходят к этой проблеме в части из них. Эстимейт — это всегда оценка, он всегда должен подразумевать оптимистическую и пессимистическую оценку. По-хорошему, должны быть указаны риски (а вдруг в другой среде всё будет не так, а вдруг, мы не сможем найти решение за указанное время, и т.п.). А руководитель уже должен руководствоваться как эстимейтом, так и рисками (которые объясняют, почему мы можем пойти по пессимистической оценке). Немного странно, что статус задачи подразумевает сроки. Сроки нужно обсуждать до начала задачи. А во время спрашивать уже о статусе. Впрочем, здесь может быть длинная дискуссия, об этом написано немало книг. Опять же, по-хорошему, в эстимейт должен входить не только сам кодинг, но и исследование, и отладка, и тестирование. Всё это должен понимать и руководитель, и разработчик еще на этапе эстимейта и оценивания рисков. Также замечу, что руководитель чутьем или опытом, должен понимать адекватны ли эстимейты и риски, и обсудить это до начала задачи. Если вы начинаете работать с плагином, с которым вы никогда не встречались, если он плохо задокументирован, если… — это риск, его нужно оценить до начала задачи. Это проблема не только разработчика, но и самого руководителя. Его должны интересовать непростые отношения с этим плагином, потому что он должен понимать, сделает ли данный разработчик эту задачу или нет. Например, если есть разработчик А (знакомый с другими плагинами) и разработчик Б (не знакомый), но разработчик А занят на других задачах, то неадекватно полагать, что разработчик Б сделает ту же задачу за то же время, только потому что руководитель так хочет.
110. Это невозможно!
Здесь уже описали действительно невозможные задачи. В каком-то смысле, этот пункт тесно завязан с предыдущим. Да и непонятно, невозможно ли вообще, или невозможно за отведенное время. Если разработчик четко указывает почему невозможно — то всё обсуждаемо.
111. Я такую ерунду делать не буду.
Да, в принципе, всё просто — или делай, или увольняйся. Но, с другой стороны, это максимализм. Из собственного опыта — если ты умеешь объяснить рациональность мотивов, что стоит за задачей и зачем она нужна — разработчик может поменять мнение или согласиться, что это необходимо.
В общем говоря, все указанные пункты, высказанные в ключе «Я начальник, поэтому разработчик будет делать, как я говорю» естественно вызвали негативную реакцию. По крайней мере, я вижу, что многие именно так и поняли данную статью. Если автор этого не подразумевал — то дело другое, но, что написано, то написано. Все проблемы вполне решаемы, где-то виновата лень, где-то отрицание (гнев, торг, депрессия), но ведь задача именно руководителя мотивировать разработчика делать работу. Люди все где-то немножко ленивы, где-то безответственны, где-то капризные. Но ведь вы их почему-то приняли на работу, а, возможно, уже проработали несколько лет. Значит, есть у них плюсы — и задача руководителя заставить эти «плюсы» работать. Ведь вы же одна команда, не так ли?
Уважаемый автор просто повторяет типовую ошибку менеджера. Я искренне прошу не воспринимать это как высокомерие, это совсем не так; единственное, почему я оставляю этот комментарий, то только потому, что поначалу сам ходил по этим же граблям и потом наблюдал, как это делают другие начинающие менеджеры.
Суть в том, что вы сейчас пытаетесь рассказать разработчику, из чего состоят ваши рабочие проблемы и хотите переучить его, объяснить ему, сделать как всем будет лучше, чтобы он вас понял и услышал, чтобы понял, зачем вы именно так а не иначе себя ведёте, чтобы посмотрел дальше своих рамок.
Реальность в том, что он живёт в мире собственных очень важных и очень сложных рабочих проблем. Я считаю, что это правильная практика, не ставить узкую задачу «от забора и до обеда», а давать небольшую вводную о проекте целиком, немножко о заказчике, о том, зачем это всё вообще делается и что и для кого должно получиться в конце. Это всё играет свою положительную роль для программиста, позволяет ему иногда проще принимать какие-то решения, ну и вообще ему так будет интереснее работать. Но это всё должно делаться коротко, в самом начале проекта, просто для общей информации и без ненужных излишеств.
Когда работа уже началась и идёт, поверьте, ему совершенно безразлично, что есть стратегии пользовательских действий, что заказчик мудак, что плохой код писал обидчивый коллега, что у вас бизнес-интересы и так далее. Он не может об этом всём думать, и не потому, что он ленив или нечуток. Просто у него там своё большое и капризное хозяйство, где продукты третьих сторон не работают, как заявлено в документации к ним, где очевидное решение не взлетает и надо искать неочевидное, где один и тот же код одинаково скомпилированный по-разному работает и это необъяснимо, где Техническое задание всегда что-то упускает (это отдельная тема, даже не буду углубляться).
И, поверьте, для него в рабочий момент это самые важные проблемы на планете. «Какой мудак это писал» — это действительно очень важно, потому что вы слышите в этой фразе «я хочу оскорбить автора кода, потому что считаю себя умнее всех», а он на самом деле имеет в виду «на этот код потребуются дополнительные трудозатраты, и я их не планировал». Фраза «у меня всё работает» означает «у меня нет никаких вводных для того, чтобы приступить к поиску ошибки, ведь, чтобы её исправить, её надо воспроизвести». И так далее.
Ему совершенно неинтересно всё, что вы тут написали, и, понимаете в чём дело, его совершенно невозможно за это осуждать. Он говорит те фразы, о которых вы пишете, потому что у него так устроена голова. Она устроена, чтобы разрабатывать программный продукт для решения поставленных задач. А не чтобы ваш бизнес зарабатывал деньги. То есть, хорошо, чтобы он понимал прямую зависимость. Но нереально (и не нужно), чтобы он думал бизнес-логикой, как вы. Он не должен думать бизнес-логикой, то есть это не исключено и такие попадаются, но мы знаем, кем они потом в итоге становятся. И, если они не такие, они не перестают быть хорошими разработчиками.
Вы не сможете переучить их говорить вашим языком. Вам придётся выучить их язык. Просто не воспринимайте их слова буквально, помните, что язык это система кодирования и декодирования. Их система кодирования мыслей не совпадает с вашей. Работайте над декодером внутри своей головы, и за пятничным пивом ваши разработчики будут говорить своим друзьям: «Ну не знаем, есть конечно дол… бы менеджеры, но у нас вроде не самый плохой вариант, вы совсем какие-то кошмары рассказываете».
Если бы они думали как вы, они были бы вами.
Суть в том, что вы сейчас пытаетесь рассказать разработчику, из чего состоят ваши рабочие проблемы и хотите переучить его, объяснить ему, сделать как всем будет лучше, чтобы он вас понял и услышал, чтобы понял, зачем вы именно так а не иначе себя ведёте, чтобы посмотрел дальше своих рамок.
Реальность в том, что он живёт в мире собственных очень важных и очень сложных рабочих проблем. Я считаю, что это правильная практика, не ставить узкую задачу «от забора и до обеда», а давать небольшую вводную о проекте целиком, немножко о заказчике, о том, зачем это всё вообще делается и что и для кого должно получиться в конце. Это всё играет свою положительную роль для программиста, позволяет ему иногда проще принимать какие-то решения, ну и вообще ему так будет интереснее работать. Но это всё должно делаться коротко, в самом начале проекта, просто для общей информации и без ненужных излишеств.
Когда работа уже началась и идёт, поверьте, ему совершенно безразлично, что есть стратегии пользовательских действий, что заказчик мудак, что плохой код писал обидчивый коллега, что у вас бизнес-интересы и так далее. Он не может об этом всём думать, и не потому, что он ленив или нечуток. Просто у него там своё большое и капризное хозяйство, где продукты третьих сторон не работают, как заявлено в документации к ним, где очевидное решение не взлетает и надо искать неочевидное, где один и тот же код одинаково скомпилированный по-разному работает и это необъяснимо, где Техническое задание всегда что-то упускает (это отдельная тема, даже не буду углубляться).
И, поверьте, для него в рабочий момент это самые важные проблемы на планете. «Какой мудак это писал» — это действительно очень важно, потому что вы слышите в этой фразе «я хочу оскорбить автора кода, потому что считаю себя умнее всех», а он на самом деле имеет в виду «на этот код потребуются дополнительные трудозатраты, и я их не планировал». Фраза «у меня всё работает» означает «у меня нет никаких вводных для того, чтобы приступить к поиску ошибки, ведь, чтобы её исправить, её надо воспроизвести». И так далее.
Ему совершенно неинтересно всё, что вы тут написали, и, понимаете в чём дело, его совершенно невозможно за это осуждать. Он говорит те фразы, о которых вы пишете, потому что у него так устроена голова. Она устроена, чтобы разрабатывать программный продукт для решения поставленных задач. А не чтобы ваш бизнес зарабатывал деньги. То есть, хорошо, чтобы он понимал прямую зависимость. Но нереально (и не нужно), чтобы он думал бизнес-логикой, как вы. Он не должен думать бизнес-логикой, то есть это не исключено и такие попадаются, но мы знаем, кем они потом в итоге становятся. И, если они не такие, они не перестают быть хорошими разработчиками.
Вы не сможете переучить их говорить вашим языком. Вам придётся выучить их язык. Просто не воспринимайте их слова буквально, помните, что язык это система кодирования и декодирования. Их система кодирования мыслей не совпадает с вашей. Работайте над декодером внутри своей головы, и за пятничным пивом ваши разработчики будут говорить своим друзьям: «Ну не знаем, есть конечно дол… бы менеджеры, но у нас вроде не самый плохой вариант, вы совсем какие-то кошмары рассказываете».
Если бы они думали как вы, они были бы вами.
Я знаю массу хороших разработчиков, которые достаточно социально компетентны и настроены на результат, чтобы не произносить таких фраз.
Моя основная претензия, что автор, по-моему, не пытается научить чему-то, а пытается отучить предлагая мало взамен. Почти все пункты о том, как не надо, и почти ничего о том, как надо.
Я бы написал примерно так:
«А у меня на компе работает» — это хорошо, но требует продолжения типа «Что я еще могу сделать чтобы выяснить причину проблемы и ее устранить? Перевести багу обратно с уточнением деталей? Изменить сообщение об ошибке на более детальное? Добавить протоколирование и диагностику?» или как крайний случай «ошибка незначительная, а воспроизводить ее очень дорого».
Если работать в таком ключе, то атмосфера совершенно другая — люди не пытаются найти виноватого, а делают общее дело. Это приятнее и дает больший результат.
Моя основная претензия, что автор, по-моему, не пытается научить чему-то, а пытается отучить предлагая мало взамен. Почти все пункты о том, как не надо, и почти ничего о том, как надо.
Я бы написал примерно так:
«А у меня на компе работает» — это хорошо, но требует продолжения типа «Что я еще могу сделать чтобы выяснить причину проблемы и ее устранить? Перевести багу обратно с уточнением деталей? Изменить сообщение об ошибке на более детальное? Добавить протоколирование и диагностику?» или как крайний случай «ошибка незначительная, а воспроизводить ее очень дорого».
Если работать в таком ключе, то атмосфера совершенно другая — люди не пытаются найти виноватого, а делают общее дело. Это приятнее и дает больший результат.
Это, пожалуй, лучший комментарий к статье. Спасибо!
Я сознательно не стал выносить это в статью и не писал в комментариях. Мне была интересна реакция массы. Напишу сейчас. Мне 36 лет, программирую с 12. Я считаю себя скорее разработчиком, а не менеджером. Да — я технический директор немаленькой компании, но я до сих пор пишу сам код, рецензирую код других разработчиков каждый день и делаю массу другой чисто технической работы. Все описанные Вами переживания мне хорошо известны и понятны. Я знаю и понимаю язык разработчиков гораздо лучше, чем большинство комментаторов в статье знают язык менеджеров. В целом согласен с Вами.
Не могу принять и согласиться с одной вещью только. Как ни был бы сложен внутренний мир разработки это не дает права разработчикам быть гиконердами и замыкаться только на своих проблемах. Поверьте, управленческие проблемы гораздо сложнее программистских. Мне есть с чем сравнивать. Но я не гружу ими своих разработчиков, они о них ничего не знают. Сложный внутренний мир и свои проблемы — это не повод усложнять коммуникации с людьми. Это никому не идет на пользу. Вы меня конечно, извините, но зачастую мы разработчики ведем себя как дети и по-детски. При этом желаем, чтобы к нам серьезно относились, принимали нас всерьез, внимательно выслушивали, хвалили и гладили по головке. Мама меня любит, мама меня поймет. Эдакий бытовой инфантилизм.
Мне, если честно, глубоко пофиг на большинство, на массовку. Я предпочитаю иметь дело с выросшими разработчиками, умеющими выслушать, понять и учесть интересы других людей и сторон. Я строю свои команды именно таким образом, эдакий разработческий спецназ. Я хотел бы, чтобы больше таких людей было вокруг и в профессии. Также по своей многолетней практике я вижу, что как правило, среди разработчиков успешны и растут профессионально и карьерно те, кто преодолели этот самый бытовой инфантилизм. Многие этого сделать не могут по разным причинам и буксуют на месте.
Моя статья о том, что приведенные мною высказывания как раз и являются одними из признаков такого инфантилизма. В довольно грубой и резкой манере я попытался объяснить почему и какой реакции я ожидаю в таких ситуациях от выросшего разработчика. Я сознательно выбрал такой формат поскольку, опять же, как показывает моя практика, мягкие увещевания в таких случаях не помогают. По реакции на статью видно, что она была неприятна многим и я, зная это, заранее извинился за резкий тон. Тем не менее, считаю что статья получилась полезной и искренне надеюсь, что она поможет кому то преодолеть этот самый инфантилизм, начиная с простых достаточно вещей.
Я сознательно не стал выносить это в статью и не писал в комментариях. Мне была интересна реакция массы. Напишу сейчас. Мне 36 лет, программирую с 12. Я считаю себя скорее разработчиком, а не менеджером. Да — я технический директор немаленькой компании, но я до сих пор пишу сам код, рецензирую код других разработчиков каждый день и делаю массу другой чисто технической работы. Все описанные Вами переживания мне хорошо известны и понятны. Я знаю и понимаю язык разработчиков гораздо лучше, чем большинство комментаторов в статье знают язык менеджеров. В целом согласен с Вами.
Не могу принять и согласиться с одной вещью только. Как ни был бы сложен внутренний мир разработки это не дает права разработчикам быть гиконердами и замыкаться только на своих проблемах. Поверьте, управленческие проблемы гораздо сложнее программистских. Мне есть с чем сравнивать. Но я не гружу ими своих разработчиков, они о них ничего не знают. Сложный внутренний мир и свои проблемы — это не повод усложнять коммуникации с людьми. Это никому не идет на пользу. Вы меня конечно, извините, но зачастую мы разработчики ведем себя как дети и по-детски. При этом желаем, чтобы к нам серьезно относились, принимали нас всерьез, внимательно выслушивали, хвалили и гладили по головке. Мама меня любит, мама меня поймет. Эдакий бытовой инфантилизм.
Мне, если честно, глубоко пофиг на большинство, на массовку. Я предпочитаю иметь дело с выросшими разработчиками, умеющими выслушать, понять и учесть интересы других людей и сторон. Я строю свои команды именно таким образом, эдакий разработческий спецназ. Я хотел бы, чтобы больше таких людей было вокруг и в профессии. Также по своей многолетней практике я вижу, что как правило, среди разработчиков успешны и растут профессионально и карьерно те, кто преодолели этот самый бытовой инфантилизм. Многие этого сделать не могут по разным причинам и буксуют на месте.
Моя статья о том, что приведенные мною высказывания как раз и являются одними из признаков такого инфантилизма. В довольно грубой и резкой манере я попытался объяснить почему и какой реакции я ожидаю в таких ситуациях от выросшего разработчика. Я сознательно выбрал такой формат поскольку, опять же, как показывает моя практика, мягкие увещевания в таких случаях не помогают. По реакции на статью видно, что она была неприятна многим и я, зная это, заранее извинился за резкий тон. Тем не менее, считаю что статья получилась полезной и искренне надеюсь, что она поможет кому то преодолеть этот самый инфантилизм, начиная с простых достаточно вещей.
ПМ Петр: Друзья, сегодня нам нужно определиться с платформой нового проекта
Программист Иван: Предлагаю PHP и Twitter bootstrap. Это простые и гибкие технологии, большинство их использует. А также…
Программист Дмитрий: Согласен с Иваном.
Тимлид Наталья: Поддерживаю.
Программист Василий: Под наши задачи есть готовый движок на ROR, и коллекция форм. В дальнейшем можно…
Что кажется участникам проекта: три голоса против одного.
Что на самом деле: одна позиция против другой позиции. Но почему когда Петр об этом сказал, Наталья, Иван и Дмитрий набросились на него с бранью?
Программист Иван: Предлагаю PHP и Twitter bootstrap. Это простые и гибкие технологии, большинство их использует. А также…
Программист Дмитрий: Согласен с Иваном.
Тимлид Наталья: Поддерживаю.
Программист Василий: Под наши задачи есть готовый движок на ROR, и коллекция форм. В дальнейшем можно…
Что кажется участникам проекта: три голоса против одного.
Что на самом деле: одна позиция против другой позиции. Но почему когда Петр об этом сказал, Наталья, Иван и Дмитрий набросились на него с бранью?
О чем сказал Петр и кто на него набросился с бранью? Не могли бы расшифровать?
Я бы сразу не согласился с порядком. В первую очередь, даже по определению, должен предлагать (определять) идеи новой платформы тимлид. Тимлид, в моем понимании это не менеджер, а это человек с большим опытом разработки и умением управлять тасками и «ручками» проекта. То есть тот, кому должны доверять те трое, ибо Наташа молодец :). Тогда ситуация поменяется. То есть когда Васька предложил рельсы, а тимлид заведомо предложил phpиху и бутстрап, то тот (Васёк) должен просто доказать, что его платформа правильней. И все… Другой вопрос, если тимлид дерево…
А, теперь понял, ну самое интересное не описано — как именно Петр об этом сказал. Я думаю проблема в этом
Ну, вероятно он не первый раз говорил непопулярные вещи, и знал, как смягчить остроту.
Будем надеяться, что он хотя бы не начал свою фразу с прямого отрицания точки зрения собеседников (типа У нас не голосование). Возможно, ему следовало вначале обговорить процедуру принятия решения, чтобы участники не раскатали губу и не чувствовали себя дураками, а может просто все не выспались и были раздражительны.
у нас даже нет прямой речи Пётра и участников совещания после первичного высказывания позиций, так что судить трудно.
А какой ответ правильный?
у нас даже нет прямой речи Пётра и участников совещания после первичного высказывания позиций, так что судить трудно.
А какой ответ правильный?
Троица испытала когнитивное искажение: они были уверены, что сам факт одобрения и разделения их идей значительной частью коллектива придает больший вес этим идеям.
То есть тимлид не подготовил их к такому решению заранее, не смог плавно перевести разговор нужное русло или не дал понять, что «набрасываться» на него неуместно?
Нет, он не искал таких сложностей. Он наивно рассчитывал, что остальные не окажутся столь Herdentiere.
Наверное тимлид недавно из технарей — они как правило не очень наблюдательные в том, что касается поведения людей?
В данной ситуации ему нужно быть не просто гипернаблюдательным, но вообще вообще гениальным политиком уровня Путина, не меньше:) А в обычной жизни опций две: конфликт или коллективное, как правило неудачное решение, на раннем этапе закрывающее фирме путь к успеху.
Под наблюдательностью я имею ввиду довольно простую вещь — интересоваться людьми вокруг себя: кто как с кем говорит и почему, у кого какие интересы, кто с кем в каких отношениях, когда вы говорите кто как вас слушает и с каким выражением лица и т.д.
Обычная жизнь весьма многообразна. Вполне возможно, что все, кроме тимлида были агрессивных и неадекватны.
Мы не знаем отношения персонажей до этого. У нас нет ни прямой речи ни интонации того, что было после высказывания мнений. Мы даже не знаем, что именно скрывается за словом «набросились», но по моему опыту, технический персонал как правило не часто открыто конфликтует с непосредственными начальниками (то есть они скорее разойдутся ворча, чем набросятся). А люди в массе своей любят транслировать высокомерие формулировками и тоном голоса. Часто этим грешат технические специалисты.
Мне как-то довелось видеть психологический тренинг, где группа людей беседовала на отвлечённые темы, а ведущий занимался тем, что в усиленном виде воспроизводил их интонации, формулировки и жесты. Оказалось у очень многих чуть ли не каждая фраза основной своей целью имеет увеличение самооценки за счет небольшого унижения собеседника. И очень часто люди сами не могут оценить тон своего голоса, пока им де его не предъявлять подобным способом.
Не знаю, что там у вас было в этой ситуации, но меня настораживают некоторые вещи в ваших формулировках:
— вы не сочли сообщили некоторые существенные подробности происходящего
— вы назвали участников Herdentiere (это типа стадо баранов да?)
— кстати выбор самого немецкого слова — нет ли в этом некоторого снобизма?
Я сам в-общем-то не психолог, а технарь, но предполагаю, что если тимлид — это вы, то просто вы чем-то задели остальных участников совещания.
И всегда существует больше чем 2 решения :)
Обычная жизнь весьма многообразна. Вполне возможно, что все, кроме тимлида были агрессивных и неадекватны.
Мы не знаем отношения персонажей до этого. У нас нет ни прямой речи ни интонации того, что было после высказывания мнений. Мы даже не знаем, что именно скрывается за словом «набросились», но по моему опыту, технический персонал как правило не часто открыто конфликтует с непосредственными начальниками (то есть они скорее разойдутся ворча, чем набросятся). А люди в массе своей любят транслировать высокомерие формулировками и тоном голоса. Часто этим грешат технические специалисты.
Мне как-то довелось видеть психологический тренинг, где группа людей беседовала на отвлечённые темы, а ведущий занимался тем, что в усиленном виде воспроизводил их интонации, формулировки и жесты. Оказалось у очень многих чуть ли не каждая фраза основной своей целью имеет увеличение самооценки за счет небольшого унижения собеседника. И очень часто люди сами не могут оценить тон своего голоса, пока им де его не предъявлять подобным способом.
Не знаю, что там у вас было в этой ситуации, но меня настораживают некоторые вещи в ваших формулировках:
— вы не сочли сообщили некоторые существенные подробности происходящего
— вы назвали участников Herdentiere (это типа стадо баранов да?)
— кстати выбор самого немецкого слова — нет ли в этом некоторого снобизма?
Я сам в-общем-то не психолог, а технарь, но предполагаю, что если тимлид — это вы, то просто вы чем-то задели остальных участников совещания.
И всегда существует больше чем 2 решения :)
Даже если вы не психолог, все равно видно что активно интересуетесь и пытаетесь смотреть на конфликт в первую очередь с психологической точки зрения (а вот vladamir в комментариях чуть выше смотрел с точки зрения начальника, — выходит, мой тест и в этом направлении работает).
Вы оказались совершенно правы в том, что данная проблема меня волнует глубоко. Когда-то я был в роли описанного ПМ-а, еще раньше — Василия (и высокомерно обижался на всех). Но психотерапия — не выход. Как ни сглаживай противоречия, в сколько нибудь сложных ситуациях группа «согласных» не откажется от своего решения. Они продолжат общаться между собой, они найдут кучу частных и косвенных доводов в пользу своего решения, они превратят эти соринки в брёвна и забросают ими все остальные предположения.
Поэтому, консультируя, я начинаю сразу с эксперимента Аша и эффекта Даннинга-Крюгера (экстраполируя на конкретные решения: мы не дураки, но можем мыслить по-дурацки). После этого становится работать проще: люди осознают, что мышление может поставить им подлянку, заставив вести себя как стадо баранов.
В описанной ситуации хуже всего поступила Наталья: как тимлид, она заранее всех выслушала и решила что поддержит общую, как она думала, точку зрения. Проекция гиперконформизма на сотрудников настолько въелась в её сознание, что она не только ожидала, но и прилагала усилия к тому, чтобы в любом, даже невыигрышном случае победило большинство. В команде было принято мыслить большинством, опираться на большинство и сливать ответственность на большинство — то есть ни на кого, по сути. ПМ же чувствовал себя лично ответственным, но он не мог сказать: давайте не будем играть в демократию, не будем потакать личным амбициям ведущего программиста, не будем подвергать проект риску с самого начала. (да! если бы он так сказал, вы бы с полным правом упрекнули его в отсутствии такта и высокомерии). Но он высказался нейтрально: что просто есть две точки зрения. Увы, в этой компании стадность зашла слишком далеко для стартапа, претендующего на успешность (хотя в группе продавцов магазина это был бы наоборот, низкий показатель), коллективное мышление вошло в рекурсию, т.е. в поисках ответов оно стало ссылаться на самого себя. Отсюда и агрессия.
Но если описанное когнитивное искажение не зашло слишком далеко, то нет ничего оскорбительного в указании группе на факт стадного мышления по какому-либо вопросу. Я думаю, в будущем эта практика широко распространится, ведь люди теряют непозволительно много мыслительных ресурсов на коллективной зацикленности.
Вы оказались совершенно правы в том, что данная проблема меня волнует глубоко. Когда-то я был в роли описанного ПМ-а, еще раньше — Василия (и высокомерно обижался на всех). Но психотерапия — не выход. Как ни сглаживай противоречия, в сколько нибудь сложных ситуациях группа «согласных» не откажется от своего решения. Они продолжат общаться между собой, они найдут кучу частных и косвенных доводов в пользу своего решения, они превратят эти соринки в брёвна и забросают ими все остальные предположения.
Поэтому, консультируя, я начинаю сразу с эксперимента Аша и эффекта Даннинга-Крюгера (экстраполируя на конкретные решения: мы не дураки, но можем мыслить по-дурацки). После этого становится работать проще: люди осознают, что мышление может поставить им подлянку, заставив вести себя как стадо баранов.
В описанной ситуации хуже всего поступила Наталья: как тимлид, она заранее всех выслушала и решила что поддержит общую, как она думала, точку зрения. Проекция гиперконформизма на сотрудников настолько въелась в её сознание, что она не только ожидала, но и прилагала усилия к тому, чтобы в любом, даже невыигрышном случае победило большинство. В команде было принято мыслить большинством, опираться на большинство и сливать ответственность на большинство — то есть ни на кого, по сути. ПМ же чувствовал себя лично ответственным, но он не мог сказать: давайте не будем играть в демократию, не будем потакать личным амбициям ведущего программиста, не будем подвергать проект риску с самого начала. (да! если бы он так сказал, вы бы с полным правом упрекнули его в отсутствии такта и высокомерии). Но он высказался нейтрально: что просто есть две точки зрения. Увы, в этой компании стадность зашла слишком далеко для стартапа, претендующего на успешность (хотя в группе продавцов магазина это был бы наоборот, низкий показатель), коллективное мышление вошло в рекурсию, т.е. в поисках ответов оно стало ссылаться на самого себя. Отсюда и агрессия.
Но если описанное когнитивное искажение не зашло слишком далеко, то нет ничего оскорбительного в указании группе на факт стадного мышления по какому-либо вопросу. Я думаю, в будущем эта практика широко распространится, ведь люди теряют непозволительно много мыслительных ресурсов на коллективной зацикленности.
Имхо в данном случае руководителю надо не обзываться «стадом» а подумать, что он может сделать для улучшения ситуации а так же. И иногда хороший руководитель — это политик и психолог.
Как вы думаете, что пм может сделать в следующий раз, чтобы исходя из тех же начальных данных достигнуть больших успехов?
Как вы думаете, что пм может сделать в следующий раз, чтобы исходя из тех же начальных данных достигнуть больших успехов?
,… А также -> а также не допустить такого в будущем.
Честолюбие <-> карьеризм, специализация <-> однобокость, коллектив <-> стадо. Не оскорбительно, просто негативно. Я считаю, в обиходе должен присутствовать этот термин, чтобы понимать, чего бояться и избегать, когда идет работа в команде.
Здоровый коллектив примет информацию о том, как выглядит принятие стадного решения, и научится отслеживать и избегать подобных ситуаций. Что делать ПМу? Вы правильно заметили вначале — избегать высокомерия. Можно сначала описать проблему неформальному лидеру — если ему важен успех, он поможет просветить остальных в каждой конкретной ситуации. Ну а если коллектив слишком увлекся стадностью — менять работу, потому что у этой фирмы нет шансов вырасти.
Здоровый коллектив примет информацию о том, как выглядит принятие стадного решения, и научится отслеживать и избегать подобных ситуаций. Что делать ПМу? Вы правильно заметили вначале — избегать высокомерия. Можно сначала описать проблему неформальному лидеру — если ему важен успех, он поможет просветить остальных в каждой конкретной ситуации. Ну а если коллектив слишком увлекся стадностью — менять работу, потому что у этой фирмы нет шансов вырасти.
стадность зашла слишком далеко для стартапа, претендующего на успешность (хотя в группе продавцов магазина это был бы наоборот, низкий показатель)Классная фраза…
Описанная ситуация сейчас выглядит как — есть 5 человек, на одного наорали, почему? А по сути — Василий должен это обсудить с Натальей и принять решение. Ситуации разные бывают. Может у них неделя на проект, ROR знает только Василий, в все остальные «на ты» только в PHP + BS.
Плюс, если в коллективе брань в порядке вещей, но наверное что-то изначально в управлении им не так?
Плюс, если в коллективе брань в порядке вещей, но наверное что-то изначально в управлении им не так?
Конечно, не так: большинство полагает, что факт признания какой-либо точки зрения этим большинством автоматически добавляет этой точке вес, без дополнительных аргументов.
Вы не учитываете момент, что не все проговаривается вслух. Если команда работает вместе не первый день, то вполне логично если они знают что, опять же, ROR знает только Василий.
Но еще раз подчеркну — дальше должно быть обсуждение или спокойный отказ. Если орут, то надо что-то править в коллективе.
Но еще раз подчеркну — дальше должно быть обсуждение или спокойный отказ. Если орут, то надо что-то править в коллективе.
В идеале — прививать любовь к рациональному мышлению, основанному на фактах и проверяемых теориях, умение вставать на разные точки зрения, сомнение, в первую очередь в коллективных идеях.
Ладно, про абстрактную группу людей можно говорить сколько угодно долго :) Нужно брать конкретику, но тогда все будет справедливо только для этих выбранных людей. Поэтому остановимся.
ХА. Я думал вы имеете ввиду конкретных людей.
В исходном примере группа абстрактная и задача такая же. Мы не знаем ни их опыта и навыков, ни возможности к обучению, ни задания и т. д. Отсюда и исходный мой коммент, что «Описанная ситуация сейчас выглядит как — есть 5 человек, на одного наорали, почему?»
С моей точки зрения задача абсолютно бессмысленна в такой постановке, я думал вы имеете дело с конкретной ситуацией, просто переобозвали участников для анонимности но готовы уточнить обстоятельства. По всей видимости, на самом деле вы задумали отгадку сначала, а потом обстоятельства уточняются так, чтобы возможной была именно она. Хотя сама идея противостояния интеллектуала пиэма стаду, возможно, и была следствием какой-то реальной ситуации, но мы не можем быть вполне уверены, что эта идея верна. Может конфликт был по другой какой-то причине, а результирующая позиция «я — интеллектуал, а вы — стадо» просто греет самолюбие ;)
Исходную ситуацию описывал father_gorry, может он и имел ввиду что-то конкретное, но не раскрыл подробностей.
Я, как и вы оба, сначала пытался объяснять класс таких ситуаций чисто психологическими проблемами, характерами, отношениями. Но потом увидел в них общее — когнитивное искажение, вызванное излишним доверием к коллективному суждению. Особенно страшно становится, когда понимаешь, что такое суждение в 95% случаев ни на чем не основано: каждый из участников не имеет достаточных знаний о вопросе, но тем не менее, приплюсовывает мнение соседа, который такой же профан, к своей уверенности.
Мне ближе концепция информированного согласия — техперсонал предлагает несколько решений, описывая достоинства и недостатки, а менеджемент выбирает, какой компромисс ему нужен
Разработчувак
Программирование это творческая работа в любом случае. Потому что дело не в готовых технологиях, а в выборе оптимального пути решения задачи. Программа может быть написана строго по ТЗ, но даже она в себе несёт свободу действия в определённом поле из ограничений:
— Как можно меньше использовать оперативной памяти;
— Как можно меньше использовать процессор;
— Как можно понятнее выглядеть, чтобы в будущем не запутаться;
— Как можно меньше содержать строк кода;
— Как можно меньше недель на это потратить.
и ещё некоторые, которые может быть я запамятовал… но все эти требования зачастую противоречивы.
Так вот, в процессе работы приходится делать множество компромиссов между ЛИБО и ЛИБО. Я видел сложные SQL запросы на десяток страниц экрана. Эта штука работает и работает правильно и быстро. Но уж лучше написать всё понятно и прозрачно шаг за шагом с комментариями. Пусть это будет работать в 10 раз медленнее, но зато в будущем будет легче найти баги и понять смысл сей магической части.
Иногда проще всё сваять быстро «чик чик и в продакшен». А иногда наоборот — как будто: «вот ведь чувсвтую, что эту функцию ещё надо будет применять тут тут и вон там ещё», хотя класс пишешь впервые. И одни методы пихаешь в родительский класс более универсальный с большим заделом на будущее, другие методы точно определяешь в дочерний класс. А потом, спустя год вновь собираешь несколько похожих методов в один родительский класс. И потратишь кучу времени на унификацию параметров, десять раз перепроверишь их типизацию, напишешь детально сообщения для ошибок, которые «ну а вдруг уж так случится что...». В итоге получается, что метод в родительском классе по большей части имеет больше проверок и сообщений об ошибках, чем функциональной необходимости. Но зато потом твой код работает правильно. А если что-то сломается, то программа тебе сама всё расскажет, покажет и сама же пользователя научит, как эту штуку надо поправить.
Это всё чистой воды программирование. Задача разработчика — разрабатывать техническое задание совместно с пользователем, чтобы получилась программа, а не знаменитая картинка про качели. Задача программиста — уложиться в некий коридор условностей, имея кучу возможных путей решения этого самого задания.
«001. А у меня на компе работает.»
А если сказать иначе: «Почему вы не хотите читать инструкцию?». Зачем смотреть картинки, где красными стрелочками написано: жать сюда сюда, потом сюда и оп? Ведь проще позвонить программисту и нажаловаться, что эта штуковина не работает.
«110. Это невозможно!»
Чувак! Подумаешь, на это ты убьёшь уйму времени, мы и не такие горы сворачивали! Но эффективное решение кроется не в построении гипер-анализа исходных данных с помощью ПК. Очень часто решение лежит рядом: нужно чтобы Петрович применил свою извилину, оторвал попу от стула, сходил в цех и спросил у Кузьмича, почему его станок жрёт масло и выдаёт брак, а не в том, чтобы пробрасывать в цех линию, навешивать датчики, и писать серверы для анализа расхода энергии, и обучать оператора Петровича нажимать 500 кнопок. Есть другое слово «Это нецелесообразно!». Затраты на решение не должны превышать затраты на отказ от решения. И слава богу, если вы умеете клиенту это объяснять, иначе он сам вам закажет уйму свистелок и перделок, а потом почешет затылок и не купит ваш продукт. Во многих местах всё ещё дешевле и проще посадить человека за стол, чем придумывать робота.
— Как можно меньше использовать оперативной памяти;
— Как можно меньше использовать процессор;
— Как можно понятнее выглядеть, чтобы в будущем не запутаться;
— Как можно меньше содержать строк кода;
— Как можно меньше недель на это потратить.
и ещё некоторые, которые может быть я запамятовал… но все эти требования зачастую противоречивы.
Так вот, в процессе работы приходится делать множество компромиссов между ЛИБО и ЛИБО. Я видел сложные SQL запросы на десяток страниц экрана. Эта штука работает и работает правильно и быстро. Но уж лучше написать всё понятно и прозрачно шаг за шагом с комментариями. Пусть это будет работать в 10 раз медленнее, но зато в будущем будет легче найти баги и понять смысл сей магической части.
Иногда проще всё сваять быстро «чик чик и в продакшен». А иногда наоборот — как будто: «вот ведь чувсвтую, что эту функцию ещё надо будет применять тут тут и вон там ещё», хотя класс пишешь впервые. И одни методы пихаешь в родительский класс более универсальный с большим заделом на будущее, другие методы точно определяешь в дочерний класс. А потом, спустя год вновь собираешь несколько похожих методов в один родительский класс. И потратишь кучу времени на унификацию параметров, десять раз перепроверишь их типизацию, напишешь детально сообщения для ошибок, которые «ну а вдруг уж так случится что...». В итоге получается, что метод в родительском классе по большей части имеет больше проверок и сообщений об ошибках, чем функциональной необходимости. Но зато потом твой код работает правильно. А если что-то сломается, то программа тебе сама всё расскажет, покажет и сама же пользователя научит, как эту штуку надо поправить.
Это всё чистой воды программирование. Задача разработчика — разрабатывать техническое задание совместно с пользователем, чтобы получилась программа, а не знаменитая картинка про качели. Задача программиста — уложиться в некий коридор условностей, имея кучу возможных путей решения этого самого задания.
«001. А у меня на компе работает.»
А если сказать иначе: «Почему вы не хотите читать инструкцию?». Зачем смотреть картинки, где красными стрелочками написано: жать сюда сюда, потом сюда и оп? Ведь проще позвонить программисту и нажаловаться, что эта штуковина не работает.
«110. Это невозможно!»
Чувак! Подумаешь, на это ты убьёшь уйму времени, мы и не такие горы сворачивали! Но эффективное решение кроется не в построении гипер-анализа исходных данных с помощью ПК. Очень часто решение лежит рядом: нужно чтобы Петрович применил свою извилину, оторвал попу от стула, сходил в цех и спросил у Кузьмича, почему его станок жрёт масло и выдаёт брак, а не в том, чтобы пробрасывать в цех линию, навешивать датчики, и писать серверы для анализа расхода энергии, и обучать оператора Петровича нажимать 500 кнопок. Есть другое слово «Это нецелесообразно!». Затраты на решение не должны превышать затраты на отказ от решения. И слава богу, если вы умеете клиенту это объяснять, иначе он сам вам закажет уйму свистелок и перделок, а потом почешет затылок и не купит ваш продукт. Во многих местах всё ещё дешевле и проще посадить человека за стол, чем придумывать робота.
Это те люди, которые вынужденно или нет пользуются творением рук твоих и что самое интересное платят за это.
Не всегда платят те, кто пользуется. И не всегда платят за то, чтобы хотели пользоваться. Недавний случай — частый косяк в воде данных, для анализа которого пришлось бы чуть ли не сильный ИИ разрабатывать, решился административным путём: кто из операторов накосячит — лишается премии.
Чувак. Во-первых, мы оба знаем, что это возможно. Нет таких задач в индустрии, которые не могла бы решить мотивированная команда или разработчик. Когда нам что-то действительно интересно и нужно, мы горы сворачиваем и делаем это.
Сильный ИИ уже разработали? См. пример выше.
Как правило, данное высказывание означает, что тебе, чувак, просто не хочется и(или) не интересно делать то, что от тебя просят, либо у тебя есть свое собственное, сильно отличающееся мнение на то, как оно должно быть сделано. Если ты профессионал, то это означает, что тебе платят деньги за выполняемую работу. Если тебя не устраивает предложенная работа, то будь мужиком, не нуди и просто поменяй ее.
Есть нюанс: при устройстве на работу круг задач и подобные условия частенько оговаривается, а если тебе предлагают делать что-то за них выходящее, то вполне можно сказать «я это делать не буду. Если нет задач, которые обещали, то или давайте договариваться по новой, или сокращайте за ненадобностью». А то доходит до того, что программист бОльшую часть времени занимается исправлением ошибок операторов в БД, а предложения выполнить свои прямые обязанности и разработать интерфейс для исправления ошибок игнорируется.
Этого в тз не было!
Спасибо! Жаль, что могу только +1, а не +100500 :)
Для гомеостаза вселенной плюсую и это: habrahabr.ru/post/208170/
Для гомеостаза вселенной плюсую и это: habrahabr.ru/post/208170/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О чем НЕ говорят разработчики или 7 любимых выражений программистов