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

[Фрося]

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

3. Почему Вы считаете, что с устной формой не получится? Ну да, фиксировать как-то надо, тут я согласен. А про остальное -- см. предыдущий абзац.

м...
Да, бумага не имеет магических свойств.
Да, не самый эффективный способ.
НО! Цель-то не только дисциплина и культура. Главная цель - доказательная база.
Т.е. для примера - просто возьмем архив конструкторской документации. Он может быть (и, как правило, есть) - электронный. Но доказательной базой (случись что... ) будут являться бумаги с подписями конкретных людей. Совершенно по-старинке лежащие в соответствующем комоде...
Да, в принципе - возможно и электронные подписи на конструкторской документайии. Я не сталкивалась - могу только предполагать - что проблем будет много.....
Поэтому на устные "хотелки" или "хотелки" зафиксированные в базе (в случае использования какого-либо пакета) -- все едино понадобится бумага с подписями.
Может и можно как-то базу юридически оформить , чтоб имела силу бумаги с подписями. Но это уже отдельная работа.

[Clauster]

м...
Да, бумага не имеет магических свойств.
Да, не самый эффективный способ.
НО! Цель-то не только дисциплина и культура. Главная цель - доказательная база.
Т.е. для примера - просто возьмем архив конструкторской документации. Он может быть (и, как правило, есть) - электронный. Но доказательной базой (случись что... ) будут являться бумаги с подписями конкретных людей. Совершенно по-старинке лежащие в соответствующем комоде...
Да, в принципе - возможно и электронные подписи на конструкторской документайии. Я не сталкивалась - могу только предполагать - что проблем будет много.....
Поэтому на устные "хотелки" или "хотелки" зафиксированные в базе (в случае использования какого-либо пакета) -- все едино понадобится бумага с подписями.
Может и можно как-то базу юридически оформить , чтоб имела силу бумаги с подписями. Но это уже отдельная работа.

А можно подробнее, зачем нужна доказательная база и бумаги с подписями? В тюрьму сажать? И как это поможет справиться с выявленной проблемой (случись что... )?

[greesha]

А можно подробнее, зачем нужна доказательная база и бумаги с подписями? В тюрьму сажать? И как это поможет справиться с выявленной проблемой (случись что... )?

Пример из жизни. Может, и не совсем в тему.

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

Подходит время сдачи первой боевой версии. И, соответственно, получения денег. Заказчик говорит: чтобы оплатить работу, сделайте нам быстренько ТЗ с указанием того, что реализовано на первом этапе и того, что будет сделано на последующих. Ничего личного, чистая формальность — бухгалтерия требует, чтобы к договору было приложено ТЗ.

Делаем ТЗ («быстренько», как и просили). Понятно: то, что уже реализовано, описать проще всего. То, что предполагается реализовать вписываем, частично основываясь на проведенных обсуждениях, частично высасываем из пальца, частично берём с потолка. Всё равно ведь чистая формальность. Отправляем ТЗ, получаем деньги. Все счастливы.

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

Деньги внезапно заканчиваются. Во всех структурах, связанных с банком, происходят масштабные сокращения. Меняется генеральный директор нашего заказчика. Все глобальные проекты забыты. Финансирование выделяется только на поддержку старых небольших проектиков, среди которых — повезло! — оказывается и наш.

Что делает новый генеральный? Правильно, достаёт из-под стола пыльное ТЗ («чистая формальность»), открывает его и смотрит: та-а-ак, что там у нас должно быть реализовано на втором этапе? Ага! ТЗ есть, договор есть, подписи стоят, функциональность и сроки реализации определены, даю отмашку: второй этап начался. Вперёд, пацаны, действуйте!

А у нас: тестировщик ушёл, аналитик сменился, директор по развитию, который общался с заказчиком, перешёл на другую работу. В общем, предметом уже никто не владеет. Открываем ТЗ, смотрим, чего мы там два года назад понаписали… и становимся унылыми-унылыми. Ей-богу, лучше бы они про наш проект вообще забыли.

[Фрося]

........... Открываем ТЗ, смотрим, чего мы там два года назад понаписали… и становимся унылыми-унылыми. Ей-богу, лучше бы они про наш проект вообще забыли.

Пример удачный.
А если софт для какой-то медицинской отрасли? И в результате багов в софте - у больных резко ухудшилось состояние? И проводится расследование: с прокурором, со следователями...
И следователи всю вашу документацию проверяют...... выполнено/не выполно, или так - на коленке лепили?

Но вроде - это совершенно отдельная и большая тема для разговора - уровень ответственности разработчика софта.

[barancev]

А если софт для какой-то медицинской отрасли? И в результате багов в софте - у больных резко ухудшилось состояние? И проводится расследование: с прокурором, со следователями...
И следователи всю вашу документацию проверяют...... выполнено/не выполно, или так - на коленке лепили?

Но вроде - это совершенно отдельная и большая тема для разговора - уровень ответственности разработчика софта.

Вот именно. Давайте не валить в одну кучу тему "как написать такие бумаги, чтобы отмазаться от ответственности" и ту, что Вы изначально заявили -- "упростит ли это выпуск релиза".

[Clauster]

........... Открываем ТЗ, смотрим, чего мы там два года назад понаписали… и становимся унылыми-унылыми. Ей-богу, лучше бы они про наш проект вообще забыли.

Это все понятно, но я не про формальные ТЗ спрашивал. Тем более в вашем примере, без разницы получается, писали бы вы тогда это ТЗ или нет. Т.е. можно было и не писать, результат тот же.

Пример удачный.
А если софт для какой-то медицинской отрасли? И в результате багов в софте - у больных резко ухудшилось состояние? И проводится расследование: с прокурором, со следователями...
И следователи всю вашу документацию проверяют...... выполнено/не выполно, или так - на коленке лепили?

Но вроде - это совершенно отдельная и большая тема для разговора - уровень ответственности разработчика софта.

Я спрашивал о том, чем наличие бумажек с подписями поможет больным, у которых ухудшилось состояние? Т.е. вместо того чтобы искать реальные проблемы, вы писали бумажки и собирали подписи. Я не говорю про то чтобы ничего не писать, просто всего должно быть в меру.

[Фрося]

По поводу выпуска релиза.
В этой ветке приведен документ "Выпуск релизов приложений". Очень разумный и хорошо структурированный.

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

По поводу разумного объема документов. Да, конечно - глупо увеличивать количество страниц просто так. Разумный объем, безусловно.

[LeshaL]

... Весь руководящий состав перетрахивается. ...

Можно поподробнее :)

[Alfa]

А можно подробнее, зачем нужна доказательная база и бумаги с подписями? В тюрьму сажать? И как это поможет справиться с выявленной проблемой (случись что... )?

Contract negotiation over customer collaboration

Видимо как-то так :).

[Clauster]

По поводу выпуска релиза.
В этой ветке приведен документ "Выпуск релизов приложений". Очень разумный и хорошо структурированный.

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

По поводу разумного объема документов. Да, конечно - глупо увеличивать количество страниц просто так. Разумный объем, безусловно.

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

[Фрося]

Прошу прощения - была запарка (мм...как я это не люблю!) потому и не отвечала.
Какой софт? Для авионики. Отсюда - и специфика.
Обсуждать? Ну... слишком специфично.
Здесь, на форуме - скоее желание "подцепить" что -то полезное и нужное. Что получается.
Почему на этом форуме? Потому как есть необходимость осознать - как ДОКУМЕНТИРОВАТЬ процесс верификации. А вот это никак без какой-то формализации процесса верификации - не получается. Во всяком случае -не вижу - как можно сделать.
Плюс - "гарантия качества". Пока, честно говоря, не укладывается - как без документирования можно качество гарантировать? Без бумаг с подписями.... И без порядка с архивацией релизов, к примеру.
Так что.... пока - осознанию, прикидываю, собираю полезное...

[Alfa]

Какой софт? Для авионики. Отсюда - и специфика.

Посмотрите Максима Дорофеева «Agile в мире снобов». Краткое описание в его блоге, презентация есть тут.

[Clauster]

Плюс - "гарантия качества". Пока, честно говоря, не укладывается - как без документирования можно качество гарантировать? Без бумаг с подписями.... И без порядка с архивацией релизов, к примеру.

Для начала надо внедрить систему менеджмента качества, хотя бы ISO 9001, а иначе никакие бумажки с подписями никакого качества не гарантируют. Но, по моему мнению, и ИСО не гарантирует никакого качества (по крайней мере в IT отрасли).

[Фрося]

Просто интересно... доклад пока не посмотрела (уф... ), только отзывы....
А Максиму Дорофееву удалось уговорить Рокфеллера?
В смысле - есть ли опыт сертификации ПО?
(.. попозже поищу в инете...но может кто-то скажет?)

[Фрося]

Вопрос снимаю... в блоге написано - что опыт есть.

(нервно начинает хихикать, сорри! Прочитав про компанию ДС-БАРС-Т - вопрос один - и как я это все провернула??????? И счас ввожу модификацию 1 го уровня.......ай.... )

[Sonja]

Haul, я когда-то оказалась в немного похожей ситуации, т.е. 2 года назад начала руководить отделом тестирования без какого-то опыта в тестировании. Но у мне, слава богу, не требовалось предоставить в сжатый срок планы реорганизаций, мне было предоставлено достаточно времени, чтобы войти в процесс и руководство оказывало поддержку. Хотя проблем было много, именно из-за недостатка опыта. Добавлю несколько советов из своего личного опыта:
1) Для начала попытайтесь хорошо понять, как шли процессы до вас, в частности, тестирование. Если что-то кажется вам совсем неправильным, несуразным и глупым - попытайтесь выяснить, почему оно делалось именно так. Причины должны быть.
2) Если начальство ждёт от вас решения каких-то проблем, выясните у него же, в чём основные проблемы - желательно конкретно, не в общих словах, и с примерами. Это понимание уже может натолкнуть на какие-то полезные идеи изменений.
3) С самого начала убедите начальство разрешить вам какую-то часть времени тратить на собственно тестирование - практический опыт необходим, знание работы изнутри придаст вам уверенности и поможет работать более качественно.
4) Не пытайтесь объять необъятное и перечитать кучу литературы о различных методиках и т.д. - их много, так как и точек зрения, лучше разобраться в самых основах.
5) Слушайте внутренний голос и интуицию. Вырабатывайте свой собственный стиль руководства.
6) Не увлекайтесь сильно планированием и тайм-менеджментом. Надо конечно, фиксировать дела, которые надо сделать, чтобы их не забыть. Принципиальные дела делайте в первую очередь, а остальные лучше делать так, как делается, как проще. Сразу становится легче жить.
7) Советуйтесь со своими сотрудниками. Чем они умнее, тем лучше. Не бойтесь, что они будут стремиться занять ваше место, не такое уж это приятное дело - руководить, и не многие мечтают этим заниматься. Большинству интереснее делать реальное дело, и они будут вам благодарны за то, что вы даёте им возможность им заниматься.

[Natalya Rukol]

Когда речь идёт не о новом департаменте/компании/проекте, а о реорганизации и улучшении текущей работы, лучше всего подходит метод, предложенный где-то в начале Алексеем. Выбираем самый узкий bottleneck и исправляем эту проблему. Видим результат. Показываем его руководству. Находим следующий ботлнек. И так дальше. Процесс нескончаемый, оно и понятно, в отсутствии развития всегда коллапс.
Плюсы такого подхода:
- Не надо городить с плеча, можно действовать "по частям" и не сводя с ума людей, привыкших к определённому укладу. Change management подразумевает подготовку людей к изменениям, а дело это непростое.
- Результаты видны сразу. Понемногу, но мы движемся вперёд, и это чувство движения несказанно радует :) Не надо ждать мега-результатов через два года, можно сделать первые шаги через месяц.
- Есть время на закрепление результатов, вхождение процедур в привычку и т.д.

У метода я знаю только один недостаток: руководство иногда не хочет понимать, почему нельзя "всё сделать супер" сегодня же? Это надо уметь объяснить :)

[SALar]

У метода я знаю только один недостаток: руководство иногда не хочет понимать, почему нельзя "всё сделать супер" сегодня же? Это надо уметь объяснить :)

"Цель" и "Синдром стога сена". Особенно последнее.
Мастер класс на тему раскрытия буду повторять. Не уверен что на неделе 20-26, но попробую в ближайшие две.

[Natalya Rukol]

"Цель" и "Синдром стога сена". Особенно последнее.

Что??

[SALar]

"Цель" и "Синдром стога сена". Особенно последнее.

Что??

Есть такие книги. Автор Элияху (Элия) Голдратт. http://www.biblion.r...s...&sku=481631