Сообщений в теме: 79

[Zhu]

с учетом что пол коллектива активно к лету решил посидеть на диете (по крайней мере женская часть)
кажется, за мисочку с конфетками меня прибьют

[elfische]

с учетом что пол коллектива активно к лету решил посидеть на диете (по крайней мере женская часть)
кажется, за мисочку с конфетками меня прибьют

Карамельки! Только вот мне нельзя такую мисочку: я на проходе сижу, конфеты кончатся не по назначению.

[Zhu]

Карамельки! Только вот мне нельзя такую мисочку: я на проходе сижу, конфеты кончатся не по назначению.

вот кстати да
одним даш - другим не дашь - обидятсо
а на всех з/п на конфетки не напасешься

[elfische]

Что-то не дошло дело до конфеток. Вернее, на моём порыве найти (выделить и подчеркнуть) повод для угощения конфеткой я была ранена в самое сердце. В результате чего началась тяжёлая кампания по улучшению процессов. Пока я не сдаю своих позиций, но до конфеток дело не дошло.

[SALar]

ошибок может сократить уровень ошибок до такой степени, что выделенное тестирование будет не нужно.

И есть ли у нас пример программного продукта, доказывающего это утверждение?

Огромное количество отличных программ было создано без тестирования. На одном из проектов, я доказал с цифрами в руках и добился остановки тестирования до встраивания качества в продукт. Дело в том, что ~ 70% ошибок были связаны с отсутствием всего двух проектных документов. И дешевле было их написать, чем тестировать.
На другом проекте мы поступили по иному. После нахождения второй типичной ошибки в ПО мы вносили еще один пункт в FAQ и рассылали его. Поиск ошибок такого типа прекращался на некоторое время, до устранения расхождений самими программистами.

Так, что да, у меня есть примеры.

Что-то не дошло дело до конфеток. Вернее, на моём порыве найти (выделить и подчеркнуть) повод для угощения конфеткой я была ранена в самое сердце. В результате чего началась тяжёлая кампания по улучшению процессов. Пока я не сдаю своих позиций, но до конфеток дело не дошло.

И еще. Посмотрите главу 18 из книги "Пространство доктора Деминга". Потом читайте всю, книгу, но сначала туда.

[elfische]

Что-то не дошло дело до конфеток. Вернее, на моём порыве найти (выделить и подчеркнуть) повод для угощения конфеткой я была ранена в самое сердце. В результате чего началась тяжёлая кампания по улучшению процессов. Пока я не сдаю своих позиций, но до конфеток дело не дошло.

И еще. Посмотрите главу 18 из книги "Пространство доктора Деминга". Потом читайте всю, книгу, но сначала туда.

По комментарию.

• "И ещё". А что было кроме и до "ещё"?
• Рекомендация книги вызвана чем именно? Желанием применять "конфетки" как мотивирующий инструмент? Или же фактом изменения процессов?

По главе.

• Это первая конкретная вещь, которую мне посоветовали с момента начала поиска информации по проблеме. Спасибо.
• К сожалению, осмысливается тяжеловато. Легче всего поняла часть про психологию. Может быть, по той причине, что старательно пытаюсь понять, что происходит в голове у коллеги. И почему оно происходит только сейчас, а не раньше.
• Пока единственное, что вынесла, -- "не делайте вредное и бесполезное". И не удивительно: сомневаюсь в том, что и как делаю в данном контексте, я же не управленец. Всего лишь хочу, чтобы мне не мешали выполнять мою работу. При этом написано, что невозможно отличить хорошее от плохого заранее наверняка. А вопрос "что делать?" никуда не исчез.

Понимаю, не бывает готовых решений и формул (А если и бывают, то это, наверняка, не есть хорошо), но мне бы сейчас нечто не настолько всеохватывающее и фундаментальное больше пригодилось (пока я дочитаю и осмыслю, столько времени уйдёт). Но данную книгу рано или поздно прочитаю в любом случае.

Не знаю, не будет ли наш дальнейший разговор оффтопом, могу дать ссылку на мою тему с проблемой в разделе управления в случае необходимости.

[SALar]

[*]Это первая конкретная вещь, которую мне посоветовали с момента начала поиска информации по проблеме. Спасибо.

Неправда.
1. Вам уже говорили про управление конфигурациями. Теперь ваш вопрос должен быть о том, где об этом читать. Ответ: SWEBOK ( http://swebok.sorlik...management.html ) - очень хорошо, но тяжеловато для начала. Поэтому идите на habrahabr и ищите по тегам "конфигурационное управление", "управление конфигурациями", "Версионный контроль" и т.д. Там где-то и моя статья есть.

2. Я вам уже давал ответ: Дефекты нужно править до написания кода, а не после него.. Не совсем понятно? Тогда вот развернутое объяснение: http://blog.shumoos.com/archives/230 . Опять непонятно? Э-э-э...

3. Может вам специалиста по тестированию пригласить? Алексея Баранцева, например? Благо сейчас он в основном и занимается тренингами и консалтингом.

Настоятельно рекомендую воспользоваться третьим советом. Впрочем, судя по вашим "наградам" вы в этом направлении двигаетесь.

[*]К сожалению, осмысливается тяжеловато. Легче всего поняла часть про психологию. Может быть, по той причине, что старательно пытаюсь понять, что происходит в голове у коллеги. И почему оно происходит только сейчас, а не раньше.
[*]Пока единственное, что вынесла, -- "не делайте вредное и бесполезное". И не удивительно: сомневаюсь в том, что и как делаю в данном контексте, я же не управленец. Всего лишь хочу, чтобы мне не мешали выполнять мою работу. При этом написано, что невозможно отличить хорошее от плохого заранее наверняка. А вопрос "что делать?" никуда не исчез.

Это одна из лучших (или лучшая) книга о менеджменте. Но она контринтуитивна.
В лучшем случае получится примерно так:
1. Что за чушь?
2. Да, ерунда все это.
3. Это неправда потому что: ...
4. Да но...
5. Да но как это сделать?!

Между первым и пятым вполне может пройти 3-10 лет. И вам сильно повезет, если вы не успеете стать "большим начальником" до достижения 4 или 5. пому как потом переучиваться существенно дольше, сложнее и дороже.

PS. То что описал топикстартер сильно похоже на "воронку Деминга" из этой же книги. Попытки компенсировать случайную ошибку ведут к ухудшению ситуации. Вместо этого нужно просто устранить корневые причины.

[elfische]

[*]Это первая конкретная вещь, которую мне посоветовали с момента начала поиска информации по проблеме. Спасибо.

Неправда.
1. Вам уже говорили про управление конфигурациями. Теперь ваш вопрос должен быть о том, где об этом читать. Ответ: SWEBOK ( http://swebok.sorlik...management.html ) - очень хорошо, но тяжеловато для начала. Поэтому идите на habrahabr и ищите по тегам "конфигурационное управление", "управление конфигурациями", "Версионный контроль" и т.д. Там где-то и моя статья есть.

Почему-то проглядела ссылку.

3. Может вам специалиста по тестированию пригласить? Алексея Баранцева, например? Благо сейчас он в основном и занимается тренингами и консалтингом.

Настоятельно рекомендую воспользоваться третьим советом. Впрочем, судя по вашим "наградам" вы в этом направлении двигаетесь.

Двигаюсь пока только я. Думаю, со временем можно будет и такую тему поднять, но сейчас бессмысленно: не готовы ещё.

2. Я вам уже давал ответ: Дефекты нужно править до написания кода, а не после него.. Не совсем понятно? Тогда вот развернутое объяснение: http://blog.shumoos.com/archives/230 . Опять непонятно? Э-э-э...

У меня проблема несколько шире, чем просто повторяющиеся баги, потому говорила в своём контексте. Но больше не буду в свою сторону заворачивать. Именно это понимаю. И тут же вопрос. Пожалуй, самое распространённое предотвращение багов -- тестирование документации. А если её нет?

[Drag]

А если ее нет - то собираем информацию и пишем ее сами :) Или собираем вещи )))))))

[elfische]

А если ее нет - то собираем информацию и пишем ее сами :) Или собираем вещи )))))))

Пока собиралась ответить, перешла в режим "собираем вещи" )))))))

[Zhu]

А если ее нет - то собираем информацию и пишем ее сами :) Или собираем вещи )))))))

Пока собиралась ответить, перешла в режим "собираем вещи" )))))))

Все что ни делается - делается к лучшему!

[elfische]

Все что ни делается - делается к лучшему!

Главное теперь -- не передумать!

[Zhu]

Главное теперь -- не передумать!


а кто ж вам теперь после всех баталий на форуме даст передумать?????=))))))

[notProgrammer]

PS. То что описал топикстартер сильно похоже на "воронку Деминга" из этой же книги. Попытки компенсировать случайную ошибку ведут к ухудшению ситуации. Вместо этого нужно просто устранить корневые причины.

Да уж, век живи - век учись. Спасибо, почитаем.
По поводу корневых проблем. Бывает так, что один офис считает корневой проблемой другой офис. Тут главное удалить правильно. Точнее, найти...

[SALar]

Да уж, век живи - век учись. Спасибо, почитаем.
По поводу корневых проблем. Бывает так, что один офис считает корневой проблемой другой офис. Тут главное удалить правильно. Точнее, найти...

Тоже мне проблему нашли. Строите диаграмму "Дерево текущей реальности" по методу из этой книги: http://www.ozon.ru/c...ail/id/5288956/ (Детмер "Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию.")


PS. Это жестокий совет. Количество матана в этой книге превышает летальную дозу для большинства людей в несколько раз.
Начните с книги "Управленческие дилеммы: Теория ограничений в действии." (Шрагенхайм) http://findbook.ru/r...artner=findbook

Она сильно проще. Но и строить диаграммы она не научит как следует.


PSS. Если нет документации - это большой дефект. Тоже можно завписать.

[elfische]

SALar, Вы явно из нас хотите менеджеров воспитать :) Но я не против.

[Фрося]

Что-то не дошло дело до конфеток. Вернее, на моём порыве найти (выделить и подчеркнуть) повод для угощения конфеткой я была ранена в самое сердце. В результате чего началась тяжёлая кампания по улучшению процессов. Пока я не сдаю своих позиций, но до конфеток дело не дошло.

Пришла из отпуска.
Главный Программист встретил словами
"Слава Богу! Вы пришли!!!!!"

Сей же момент что-то поприсылал по почте, сам (!!!!!) завис над столом и в терминах "Ну короче -- вот -- тута кое-что..Ну гляньте.. Ну тута так, тама сяк.. короче менюшки...а фик знает.. ну так вроде .."

Пошла собирать бумажки-железки, выслушивать и записывать --- чего понаделали и что поменяли!

ПС. Не! Конфеты рулят!

[SALar]

SALar, Вы явно из нас хотите менеджеров воспитать :) Но я не против.

Я сторонник системы "сменных командиров" описанной нашим соотечественником в 1935 году. Впоследствии с успехом используемой хитроумными японцами и многими другими. В частности IBM. Вы не сможете быть хорошим инженером, если не знаете (не можете выполнять) работу своего руководителя.

[elfische]

"Слава Богу! Вы пришли!!!!!"

ПС. Не! Конфеты рулят!

Здорово, что встречают, как дома! У меня пока есть время, может, ещё успею внедрить конфеты!

Я сторонник системы "сменных командиров" описанной нашим соотечественником в 1935 году. Впоследствии с успехом используемой хитроумными японцами и многими другими. В частности IBM. Вы не сможете быть хорошим инженером, если не знаете (не можете выполнять) работу своего руководителя.

Позволю себе не согласиться. На своём же примере.

[SALar]

Я сторонник системы "сменных командиров" описанной нашим соотечественником в 1935 году. Впоследствии с успехом используемой хитроумными японцами и многими другими. В частности IBM. Вы не сможете быть хорошим инженером, если не знаете (не можете выполнять) работу своего руководителя.

Позволю себе не согласиться. На своём же примере.

http://gaperton.live....com/44653.html

...
В некоторых подразделениях IBM уделялось очень большое внимание ликвидации «вертикального расслоения» - сокращению дистанции и борьбы с недоверием между менеджментом и инженерами. Меры в частности включали в себя обязательную ротацию — каждый инженер обязан провести как минимум один проект в роли менеджера.

Любопытная деталь — когда инженер получает назначение на менеджера, ему оставляют его зарплату. И, после завершения проекта, его переводят обратно в инженеры, и при этом поднимают ему зарплату.

Меры IBM нацелены в корень данной проблемы, суть которой составляют человеческие отношения. Они нацелены на формирование единой команды менеджмент-подчиненные, и укреплению доверия.
...

Не хотите, чтобы вам подняли зарплату - не соглашайтесь.