Здравствуйте, SEDEGOFF, Вы писали:
SED>Здравствуйте, Sshur, Вы писали:
S>>Нет, на работу он как часы ходит. А вот тесты может "забыть" написать, или решит, что они не нужны так как тривиальны. Кто в этом случае виноват? SED>Что значит Решит? У него есть на это право? Если есть и вас эти решения не устраивают то или заберите это право или избавьтесь от человека. S>>И как с этим должен справиться идеальный менеджмент? SED>Зачем же идеальный? Тут и обычного хватит. По моему посту ниже вы даже можете догадаться как
Собственно, о чем спорим то? Исходный тезис исходя из байки про слугу купца был, что первый слуга ни в чем не виноват, ему просто не дали детальных указаний. Ну а теперь все говорят, что его давно надо было гнать в шею, что раз он за годы службы не понял, какую информацию хочет узнать купец, спрашивая о проходящем караване
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, SEDEGOFF, Вы писали:
SED>Здравствуйте, Sshur, Вы писали:
S>>А вот этот процесс как раз точно задокументировать нельзя И у каждого разработчика свое понимание, S>>и кто-то будет писать подробно, а кто-то нет. То есть все равно детали выполнения задания отдаются на откуп разработчику. Вот мы пришли к тому, что абсолютно конкретно и детально поставить подчиненному задание нельзя, по крайней мере в сфере разработки ПО. SED>ой! Привидите пожалуйста пример, когда у вас это не получилось. Я встречал задачи, которые на первый взгляд не имели конкретики. Но это на первый взгляд. Во всех задачах, которые я ставил за свою недолгую жизнь, я видел конкретные цели. Другое дело исполнители мне попадались такие, которым приходилось дольше эти цели объяснять. Ну да ладно — пример задачи в студию!
Немножко не так. Нельзя поставить подчиненному задание не потому, что это в принципе невозможно, а потому, что если разжевывать все до оператора — зачем тогда подчиненный?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Собственно, о чем спорим то? Исходный тезис исходя из байки про слугу купца был, что первый слуга ни в чем не виноват, ему просто не дали детальных указаний. Ну а теперь все говорят, что его давно надо было гнать в шею, что раз он за годы службы не понял, какую информацию хочет узнать купец, спрашивая о проходящем караване
Ну не спорим — диалог у нас.
Каждое слово имеет свое значение в зависимости от контекста в котором оно сказано. Вот эта байка про купца. Я конечно не купец и всех деталей не знаю. Но совсем утрировано так (при условии наличия лояльности и желаний у меня как у работника компании): Босс направляет к потенциальному партнеру с вопросом. Наша работа — покупать и продавать. Если меня он туда посылает — значит есть в этом какой то инетер. И вот пошло разделение:
1. Человек тупо выполнил поставленную задачу — получил ответ на вопрос
2. Человек задал не только заданный вопрос, но и собрал информацию в контексте своей работы. Не потому что он знал что его спросят, а потому что знал какая информация может быть потенциально интересна.
Перенося в ПО, можно представить это так: У вас есть два программиста — работают у вас три года. Преданы компании и все дела. Вы даете одну задачу: изучить возможность написать программу Hello Word с использованием СОМ технологии.
1. Первый отвечает — это не возможно
2. Второй дает развернутый ответ: почему это не возможно, как это все таки сделать и какие есть еще варианты вывода Hello Word на экран пользователя.
Здравствуйте, Sshur, Вы писали: S>Немножко не так. Нельзя поставить подчиненному задание не потому, что это в принципе невозможно, а потому, что если разжевывать все до оператора — зачем тогда подчиненный?
ааа — ок. Тут как всегда все относительно — если вы делаете это постоянно одному и тому же человеку — ваш вапрос абсолютно верен, но не совсем Если разжевать можно за два дня, а делать это неделю? То вот подчиненный это и сделает. Но лень великая сила! Каждый истинно линивый руководитель рано или поздно избавится от такого подчинненого.
SED>Ну не спорим — диалог у нас. SED>Каждое слово имеет свое значение в зависимости от контекста в котором оно сказано. Вот эта байка про купца. Я конечно не купец и всех деталей не знаю. Но совсем утрировано так (при условии наличия лояльности и желаний у меня как у работника компании): Босс направляет к потенциальному партнеру с вопросом. Наша работа — покупать и продавать. Если меня он туда посылает — значит есть в этом какой то инетер. И вот пошло разделение: SED>1. Человек тупо выполнил поставленную задачу — получил ответ на вопрос SED>2. Человек задал не только заданный вопрос, но и собрал информацию в контексте своей работы. Не потому что он знал что его спросят, а потому что знал какая информация может быть потенциально интересна.
Я бы и третий вариант назвал — мимо купца проходит не первый караван, и второй слуга знает, какого рода информация интересна купцу. Ну и может быть, когда-то он точно так же как и первый слуга сбегал несколько раз и купец ему объяснил, что нужно узнать.
SED>Перенося в ПО, можно представить это так: У вас есть два программиста — работают у вас три года. Преданы компании и все дела. Вы даете одну задачу: изучить возможность написать программу Hello Word с использованием СОМ технологии. SED>1. Первый отвечает — это не возможно SED>2. Второй дает развернутый ответ: почему это не возможно, как это все таки сделать и какие есть еще варианты вывода Hello Word на экран пользователя. SED>
Хороший пример из области разработки ПО Andy77 где-то выше по топику предоставил.
Кстати, разделение по двум пунктам можно сделать. Приходилось ли слуге раньше выполнять подобные поручения, или нет. Если да, и он до сих пор не понял, что хочет купец — то гнать его в шею. Если нет, то получается слуга действительно лучше купца знает, что тот хочет и это из области фантастики. Я всегда имел в виду первый вариант.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Я бы и третий вариант назвал — мимо купца проходит не первый караван, и второй слуга знает, какого рода информация интересна купцу. Ну и может быть, когда-то он точно так же как и первый слуга сбегал несколько раз и купец ему объяснил, что нужно узнать.
ну все правильно. Только наверное не третий вариант — а истори развития работника из второго варианта
S>Хороший пример из области разработки ПО Andy77 где-то выше по топику предоставил.
Он рассказал что у него происходит. И как я понял, он вынужден с такими людми работать. S>Кстати, разделение по двум пунктам можно сделать. Приходилось ли слуге раньше выполнять подобные поручения, или нет. Если да, и он до сих пор не понял, что хочет купец — то гнать его в шею.
Точно! S>Если нет, то получается слуга действительно лучше купца знает, что тот хочет и это из области фантастики. Я всегда имел в виду первый вариант. Низнаю как это правильно назвать... Советник что ли. В общем человек, который за определенный бонус вводит бест-практикс сверху вниз. И это реальность. Такие люди только за одно предложения получают столько, сколько мы за год. Но правда и не совсем слуги они
Здравствуйте, bkat, Вы писали:
B>>>а в этом топике требуют детальных инструкций по тому, как дышать. CC>>Ты не путай. Тут хотят чтоб задача была сформулирована в понятном виде, без "угадушек".
B>Что значит понятно? Это все индивидуально.
Понятно — это означает понятно. Должна быть точно и недвусмысленно обозначена проблема, которую надо решить. А не расписаны детали решения.
Здравствуйте, Sshur, Вы писали:
S>Собственно, о чем спорим то? Исходный тезис исходя из байки про слугу купца был, что первый слуга ни в чем не виноват, ему просто не дали детальных указаний.
Ему не обозначили проблему и цель, из которой он мог бы вывести детали. Не надо путать это с детальными указаниями.
S>Ну а теперь все говорят, что его давно надо было гнать в шею, что раз он за годы службы не понял, какую информацию хочет узнать купец, спрашивая о проходящем караване
Эту байку можно интерпретировать как угодно, если дофантазировать деталей.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bkat, Вы писали:
B>>>>а в этом топике требуют детальных инструкций по тому, как дышать. CC>>>Ты не путай. Тут хотят чтоб задача была сформулирована в понятном виде, без "угадушек".
B>>Что значит понятно? Это все индивидуально.
G>Понятно — это означает понятно. Должна быть точно и недвусмысленно обозначена проблема, которую надо решить. А не расписаны детали решения.
Дак с этим не спорю.
Я лишь утверждаю, что понятность — это весьма индивидуально.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, bkat, Вы писали:
B>>>>>а в этом топике требуют детальных инструкций по тому, как дышать. CC>>>>Ты не путай. Тут хотят чтоб задача была сформулирована в понятном виде, без "угадушек".
B>>>Что значит понятно? Это все индивидуально.
G>>Понятно — это означает понятно. Должна быть точно и недвусмысленно обозначена проблема, которую надо решить. А не расписаны детали решения.
B>Дак с этим не спорю. B>Я лишь утверждаю, что понятность — это весьма индивидуально.
Проблема с купцом в рассказе — он не обозначил проблему.
Здравствуйте, Gaperton, Вы писали:
G>Проблема с купцом в рассказе — он не обозначил проблему.
Ну да ладно тебе, это же притча, и я не думаю, что её соль заключается в том, что "купец не обозначил проблему". Возьми другой пример — притчу о лягушке, попавшей в кувшин с молоком, но не сдавшейся и барахтавшейся в кувшине до тех пор, пока не взбила молоко в сметану и не выбралась оттуда. Можно сказать, что соль притчи в том, что руководитель проекта забыл закрыть кувшин крышкой; однако же, большинство людей понимают её так, что не следует сдаваться даже в, казалось бы, безнадежных ситуациях.
Здравствуйте, Andy77, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Проблема с купцом в рассказе — он не обозначил проблему.
A>Ну да ладно тебе, это же притча
Тут видимо начинает сказываться образ мышления программистов.
Ничего не поделаешь, но нам, программистам, очень важно воспринимать вещи буквально.
Потому и притчи порой начинаем воспринимать абсолютно буквально
и на полном серьезе обсуждать того купца и проводить наипрямейшие параллели с проектами.
Здравствуйте, Andy77, Вы писали:
G>>Проблема с купцом в рассказе — он не обозначил проблему.
A>Ну да ладно тебе, это же притча, и я не думаю, что её соль заключается в том, что "купец не обозначил проблему".
Мы же эту притчу не в абстрактно-бытовом контексте обсуждаем, а в контексте управления, не так ли? Так вот, в чем соль притчи (то есть что хотел сказать автор) понятно, но тем не менее, в контексте управления это отвратительная притча, ибо купец не обозначил проблему (то есть сказал он это плохо). Эта притча является отличным примером, как не надо давать указаний, хотел сказать это автор, или нет. И не самым лучшим примером, как надо выполнять плохие указания. Это если читать, "что написано", а не додумывать, что хотел сказать автор.
A>Возьми другой пример — притчу о лягушке, попавшей в кувшин с молоком, но не сдавшейся и барахтавшейся в кувшине до тех пор, пока не взбила молоко в сметану и не выбралась оттуда. Можно сказать, что соль притчи в том, что руководитель проекта забыл закрыть кувшин крышкой; однако же, большинство людей понимают её так, что не следует сдаваться даже в, казалось бы, безнадежных ситуациях.
Понимание притч определяется контекстом, в который их помещают. Эта притча пока не приводилась как пример управления сотрудниками. А вот если ты ее приведешь в таком качестве, то ее мораль может быть, например, другой — "надо бросать сотрудников проект методом "учитесь плавать", и "хороший" сотрудник должен выплыть, сбив молоко в сметану". И тут же тебе накомментируют.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Andy77, Вы писали:
G>>>Проблема с купцом в рассказе — он не обозначил проблему.
A>>Ну да ладно тебе, это же притча, и я не думаю, что её соль заключается в том, что "купец не обозначил проблему".
G>Мы же эту притчу не в абстрактно-бытовом контексте обсуждаем, а в контексте управления, не так ли? Так вот, в чем соль притчи (то есть что хотел сказать автор) понятно, но тем не менее, в контексте управления это отвратительная притча, ибо купец не обозначил проблему (то есть сказал он это плохо). Эта притча является отличным примером, как не надо давать указаний, хотел сказать это автор, или нет. И не самым лучшим примером, как надо выполнять плохие указания. Это если читать, "что написано", а не додумывать, что хотел сказать автор.
Это в контексте программирования купец не обозначил проблему. А в контексте торговли узнать, что это за караван вполне четко подразумевает сбор сведений о том что и по чем везет караван. Если перевести байку в наш контекст, то получится, что на производство послали аналитика (или постановщика задач) с задачей "узнать что это за производство", и он выяснил из какого сырья и по каким выкройкам делает фуфайки ООО "Пупкин и ко", но ничего не выяснил про их бизнес-процессы.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
В общем разобрались:
— для управления плохая притча
— для аналитики хорошая (в том числе и в плане предугадывания изменений требований)
Интересно, как для ситуаций пересечения областей ответственности?
Здравствуйте, Sshur, Вы писали:
S>Это в контексте программирования купец не обозначил проблему. А в контексте торговли узнать, что это за караван вполне четко подразумевает сбор сведений о том что и по чем везет караван.
Ок, предположим что так.
S>Если перевести байку в наш контекст, то получится, что на производство послали аналитика (или постановщика задач) с задачей "узнать что это за производство", и он выяснил из какого сырья и по каким выкройкам делает фуфайки ООО "Пупкин и ко", но ничего не выяснил про их бизнес-процессы.
Не. Даже тогда получится, что вместо аналитика на производство заслали кого-попало, не поставив ему толком проблему .
Здравствуйте, Gaperton, Вы писали:
B>>Что значит понятно? Это все индивидуально.
G>Понятно — это означает понятно. Должна быть точно и недвусмысленно обозначена проблема, которую надо решить. А не расписаны детали решения.
Здравствуйте, Gaperton, Вы писали:
B>>>Что значит понятно? Это все индивидуально.
G>>Понятно — это означает понятно. Должна быть точно и недвусмысленно обозначена проблема, которую надо решить. А не расписаны детали решения.
G>Das ist auftragstaktik. Verstanden?
В любом случае dagegen ist nichts zu machen, сам понимаешь
Здравствуйте, SEDEGOFF, Вы писали:
S>Миру нужны такие люди. Очень нужны. Люди, которые способны ДОСТАВИТЬ ПИСЬМО ГАРСИИ.
Миру нужны такие программы. Очень нужны. Программы, в интерфейсе которых — одна большая кнопка "СДЕЛАЙ МНЕ ЗАШИБИСЬ".
Это эссе — "мечта генерала": чтобы рядом был "толковый майор".
Клерк, которому говорят "доставь письмо Гарсии", а он отвечает "есть-сэр!" — это плохой клерк. Он берёт на себя неопределённые обязательства и даёт заказчику иллюзию гарантии.
Как минимум, ему нужно узнать, кто такой Гарсия и где его искать. И как долго бегать за этим Гарсией, чтобы не получилось "ой, а я уже сорок лет поезда под откос пускаю".
Разумеется, заказы могут быть сформулированы по-разному — вплоть до "я сам без понятия кто этот ваш Гарсия, но если встретишь его, передай..." и даже "а мне пофиг, я сказал передай Гарсии, и баста". Ну если клиент платит за такое (или ещё почему-то это нужно), то можно и побегать.
И у каждого разработчика свое понимание,
Перекуём баги на фичи!
