Перейти к содержимому

Фотография

Непрофессиональные проблемы тестирования


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 19

#1 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 12 ноября 2006 - 20:56

Публикация компании QAExpert.

Непрофессиональные проблемы тестирования в постсоветском государстве
Автор: Ростислав Борук

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

Спросите: "Почему именно в постсоветском государстве? Подобные проблемы есть почти везде". По одной простой причине: в постсоветском государстве эти проблемы имеют свои корни и специфику, ввиду уникального менталитета живущих тут людей, как руководителей так и тестировщиков. Именно по этому я буду использовать термин "наши" люди в кавычках, что бы было понятно, что речь идет о людях выросших и живущих в постоветском государстве.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#2 chuk

chuk

    Новый участник

  • Members
  • Pip
  • 37 сообщений

Отправлено 13 ноября 2006 - 14:05

Спасибо,
интересная публикация.
В общем - ничего нового, но тут все систематизировано и хорошо представлено. Спасибо.

Единственный коммент по части:

"Сроки на тестирование заведомо недостаточные (безобразное руководство)
Как убедить руководство, что надо больше времени?"

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

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

Вот в этой ситуации и приходится выбирать: самый простой вариант (и самый 1-й в списке) пойти и обоснованно доложить руководству - что есть вот такие проблемы и приемлемое качество обеспечно не будет.

Если бы все дело было только в руководителе - то вопрос решался бы однозначно - дополнительнйы анализ + пересмотр планов + сроков.

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

Вот тут начинается интересная история - можно отказаться от заведомо проблемного проекта, можно заранее объяснить кастомеру - что будет плохо (но на такого рода заявления, особенно в начале проекта - кастомер обычно не реагирует и витает в облаках). Можно искать доп ресурсы себе в убыток - лишь бы удовлетворить кастомера (но все время себе в убыток работать не будешь). Можно просто плюнуть на все - коль эти проблемы решить нельзя (с кастомером) или обидеться на руководителя (что он по каким-то причинам не в состоянии их решить) и продолжать работу по принципу "делать все, что могу, а дальше - как получиться".

один из предложенных автором статьи вариантов - "поиск нового места работы" не всегда адекватен, так как такие проекты иногда (а бывает, что и не иногда, а чаще) появляются на любых фирмах.

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

По моему мнению в такой ситуации надо принудительно самому поломать все настроенные процессы тестирования.

Вот допустим есть у меня процесс QA для "стандартного" и "благополучного" процесса, когда и сроки в пределах разумного и ресурсы более-менее обеспечены. И тут приходит такой проект. В этой ситуации все, пришел полный конец, надо быстренько забыть в принципе о таком понятии, как процесс обеспечения качества разрабатываемого продукта. Так как качество на таком проекте в принципе не зависит от процесса QA, он вообще не работает на таких проектах.

В этой ситуации единственное, что может спасти проект в части QA (если не считать случая, когда вообще от него отказаться или уволиться) - это перераспределение ресурсов QA между проектами так, чтобы на таком проблемной проекте оказались "сливки" QA команды, которые обладают огромным опытом и некоторыми "ведическими" знаниями в области тестинга - это может хоть частично компенсировать нехватку времени, отбросить некоторые несущественные формальные процедуры процесса обеспечения качества, максимально минимизировать время на менеджмент тест кейсов, баг трэкинг и максимально сосредоточиться на анализе требований и очень тесной кооперации с девелоперами. Уже один грамотный анализ требований может на во время 1-й недели проекта отсечь порядка 30 % проблемных и бажных мест (проценты взяты из собственного опыта).

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

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

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

а вообще было бы интересно - может кто-то еще поделится опытом - как решать задачи QA в условиях явного недостатка ресурсов (как временных так и людских).

спасибо,
Александр
  • 0

#3 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 13 ноября 2006 - 14:56

Спасибо Александр. Уже даже за то, что Вы столько написали, за это отдельное спасибо.

Спасибо,
интересная публикация.
В общем - ничего нового, но тут все систематизировано и хорошо представлено. Спасибо.

Единственный коммент по части:

"Сроки на тестирование заведомо недостаточные (безобразное руководство)
Как убедить руководство, что надо больше времени?"

Просмотр сообщения


Рад что для Вас тут нет ничего нового... :ok:
То как вы поняли "Сроки на тестирование заведомо недостаточные (безобразное руководство)", на самом деле вы описали раздел "Нет возможности добавить ресурсы". + В описании данного случая указывается что если причины есть нормальные, например: пилот и мы получим много проектов если получится, или ребята, это начало стратегического сотрудничества. Тут все понятно. Я же описал ситуацию, когда "А потому что сразу не продумали, или еще хуже, не захотели тратить времени и средств" - это типичная проблема везде, когда берешься не за свое дело, а если, при этом, нет желания его делать, то результаты прогнозируемы и очевидны.

Вот в этой ситуации и приходится выбирать: самый простой вариант (и самый 1-й в списке) пойти и обоснованно доложить руководству - что есть вот такие проблемы и приемлемое качество обеспечно не будет.

Просмотр сообщения


Я бы сформулировал иначе. "Требуемое" качество обеспечено не будет. Или вот так, будет покрыто тестами 60% программы. Ну вот где-то так.

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

Просмотр сообщения


Основная мысль, красной нитью, если руководитель нормальный, то он прямо скажет о причине такого "ведения" проекта.
Тогда решение о смене компании - не единственный вариант.

В этой ситуации единственное, что может спасти проект в части QA (если не считать случая, когда вообще от него отказаться или уволиться) - это перераспределение ресурсов QA между проектами так, чтобы на таком проблемной проекте оказались "сливки" QA команды, которые обладают огромным опытом и некоторыми "ведическими" знаниями в области тестинга - это может хоть частично компенсировать нехватку времени, отбросить некоторые несущественные формальные процедуры процесса обеспечения качества, максимально минимизировать время на менеджмент тест кейсов, баг трэкинг и максимально сосредоточиться на анализе требований и очень тесной кооперации с девелоперами. Уже один грамотный анализ требований может на во время 1-й недели проекта отсечь порядка 30 % проблемных и бажных мест (проценты взяты из собственного опыта).

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

Просмотр сообщения


Может помочь, а может завалить все остальные проекты. :lol: Это как вам повезет со "сливками" и наличием других проектов (я уже не говорю про наличие самих "сливок" и их уровень)

И еще вы предлагаете переложить проблему на плечи тестера? :acute:

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

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

Просмотр сообщения


Про опыт согласен на все 100%... Однако не стоит никогда обещать того, что не можешь сделать. И разговаривать надо на уровне того что можешь предложить, а не того, что хотел бы предложить. Однако, это тема немного из другой плоскости. :friends:

а вообще было бы интересно - может кто-то еще поделится опытом - как решать задачи QA в условиях явного недостатка ресурсов (как временных так и людских).

спасибо,
Александр

Просмотр сообщения


и Вам спасибо. :good:
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#4 Pulsar

Pulsar

    Новый участник

  • Members
  • Pip
  • 54 сообщений
  • Город:dp.ua

Отправлено 13 ноября 2006 - 18:30

а вообще было бы интересно - может кто-то еще поделится опытом - как решать задачи QA в условиях явного недостатка ресурсов (как временных так и людских).

Например, по людским ресурсам, в другой статье
http://www.qaexpert....development.htm
написано: "Иначе Вы можете потратить очень много средств на дорогого консультанта, пока будете выяснять что же Вам от него надо. Это Вам обойдется недешево, зато в результате Вы можете нанять не очень дорогого и сравнительно молодого специалиста".
Вот здесь слово молодого можно убрать и уже получится дополнительное решение. Видел как взяли в тестирование человека возрастом за 50 лет.
  • 0

#5 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 13 ноября 2006 - 19:23

Например, по людским ресурсам, в другой статье
http://www.qaexpert....development.htm
написано: "Иначе Вы можете потратить очень много средств на дорогого консультанта, пока будете выяснять что же Вам от него надо. Это Вам обойдется недешево, зато в результате Вы можете нанять не очень дорогого и сравнительно молодого специалиста".
Вот здесь слово молодого можно убрать и уже получится дополнительное решение. Видел как взяли в тестирование человека возрастом за 50 лет.

Просмотр сообщения


Я бы не назвал это дополнительным решением. :friends:
Это, скорее, одна из реализаций того же решения. :lol:
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#6 Pulsar

Pulsar

    Новый участник

  • Members
  • Pip
  • 54 сообщений
  • Город:dp.ua

Отправлено 13 ноября 2006 - 20:02

Например, по людским ресурсам, в другой статье
http://www.qaexpert....development.htm
написано: "Иначе Вы можете потратить очень много средств на дорогого консультанта, пока будете выяснять что же Вам от него надо. Это Вам обойдется недешево, зато в результате Вы можете нанять не очень дорогого и сравнительно молодого специалиста".
Вот здесь слово молодого можно убрать и уже получится дополнительное решение. Видел как взяли в тестирование человека возрастом за 50 лет.

Просмотр сообщения


Я бы не назвал это дополнительным решением. :friends:
Это, скорее, одна из реализаций того же решения. :acute:

Просмотр сообщения

Можно и так конечно, но у постсоветских фирм думаю есть этот странный бзик ;) насчет возраста.
И в этой публикации слово молодой почему-то промелькнуло.
Так вот думаю если если есть барьеры по возрасту - это будет дополнительное решение. А если нет, то еще одна реализация того же.
:lol:
  • 0

#7 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 13 ноября 2006 - 20:51

Можно и так конечно, но у постсоветских фирм думаю есть этот странный бзик ;) насчет возраста.
И в этой публикации слово молодой почему-то промелькнуло.
Так вот думаю если если есть барьеры по возрасту - это будет дополнительное решение. А если нет, то еще одна реализация того же.
:lol:

Просмотр сообщения


Все наши компании, в какой-то мере, постсоветские. :friends:
Молодой - промелькнуло, потому что, на мой взгляд, компании, которые доросли до услуг внешних консультантов, должны видеть перспективу в молодых специалистах, готовых обучиться, разобраться и нести дальше светлое и прекрасное.

Кстати, Вы говорите про барьер по возрасту снизу или сверху?
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#8 Pulsar

Pulsar

    Новый участник

  • Members
  • Pip
  • 54 сообщений
  • Город:dp.ua

Отправлено 14 ноября 2006 - 10:45

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

Они и так видят, даже те что не доросли ;) до консультантов.

Кстати, Вы говорите про барьер по возрасту снизу или сверху?

Я про объявления: "Возраст до 35 лет или до 40 лет ..."
  • 0

#9 chuk

chuk

    Новый участник

  • Members
  • Pip
  • 37 сообщений

Отправлено 14 ноября 2006 - 17:05

Слава,
спасибо за комменты,

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

И в такой ситуации уже как бы все равно - почему так случилось - надо либо делать, либо действительно увольняться. Какая мне разница, что ко мне подойдет мой руководитель и будет мне долго и нудно объяснять, почему так произошло, но если такой проект у меня уже на руках и я принял решение с ним работать - то тут уже интереснее - что же я с ним могу сделать.


Небольшой коммент по фразе:

"... Я же описал ситуацию, когда "А потому что сразу не продумали, или еще хуже, не захотели тратить времени и средств" - это типичная проблема везде, когда берешься не за свое дело, а если, при этом, нет желания его делать, то результаты прогнозируемы и очевидны."

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

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

Это можно предложить только в пределах учебного курса (по принципу "как закалялась сталь" -- чтобы другие "однодневки" не попались на этом). Возможно, что публикация как раз для этого и предназначена.

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

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

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

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

В основном мы получали такие проекты в моменты кризисов, когда уже не приходилось выбирать и не было возможности диктовать свои условия.

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

Если не трудно - поделитесь опытом (я больше чем уверен, что у Вас тоже были такие проекты) - как Вы выходили из таких ситуаций ? Это не "вопрос-подколка". Мне действительно интересно знать - как в условиях кризиса ресурсов (не важно, по каким причинам) можно выйти из подобных ситуаций ?

Есть достаточно много публикаций по менеджменту в кризисных ситуациях, но они какие-то абстрактные - общие фразы только. Если есть возможность, не могли бы Вы или может еще кто-то, кто читает эту ветку просто кратко расписать - что же я буду делать как QA Manager на таком проекте.

Я свой вариант представил - возможно он и не очень, но в свое время он помог. Может есть еще какие варианты кризис-менеджмента (но только с точки зрения работы QA). Если можно - то без общий линок на общеизвестные ресурсы по кризис - менеджменту. Просто своими словами - что надо делать.

Сорри, что вот так напрягаю в пределах этой ветки.

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

Если рассматривать только причины - то Вы абсолютно правы в своей публикации, а если рассматривать способы реакции на такой проект - вот тут я и пытаюсь расписать.

насчет плечей тестера - проекты разные бывают, бывает, что QA работает на внешнего разработчика, тогда кроме QA на проекте со стороны фирмы больше никого и нет - т.е. все QA однозначно ложиться на наши плечи и успех проекта только на этом и стоит (успех - это имеется ввиду удовлетворение подрядчика/заказчика в результатах работы QA). И ведь достаточно часто просто ставят перед фактом - есть сроки, есть объемы а дальше - как хотите.
Т.е. тут вы однозначно правы - все ложиться на поечи QA. Но я не хочу, чтобы сложилось такое мнение, что имея такой проект нас отдавали на растерзание. Наоборот - у нас была "зеленая улица" по любым хотениям и желаниям вплоть до кофе в постель :), т.к. все прекрасно понимали, что от нашей работы очень многое зависит. Это опять же - к вопросу о том, что руководство чаще всего отлично понимает - что это за проект и "откуда ноги растут". Поэтому я и не рассматриваю вариант с Идиотом-руководителем

Если мы рассматриваем вариант, когда девелоперы и QA сидят вместе в одной лодке, то конечно QA - это не мальчики для битья и не ответчики за весь проект, но именно на таких проблемных проектах очень хорошо видно, что без QA вообще никак, т.е. у тех, у кого еще хоть немного оставались крупинки сомнения о "дармоедах" из QA Team - после таких проектов обычно все сомнения уходят. И кооперация c QA на таких проектах очень интересная -вплоть до парной работы и совместного просмотра кода. В некоторых местах почти по XP. Иногда я ловлю себя на мысли, что может быть XP как раз и подходит оптимально для таких проектов, но все равно - в чистом виде я даже и не пытался его использовать там. Даже мыслей не было о каких-то особых процессах на таком проекте - просто в чистом виде креатив по тестированию :).

сорри за длинные пояснения.

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

Я пока не смог определиться в области (как я себе ее сам называю) экстремального тестинга.

По процессам работать легко, особенно если они настроены, а даже если они и не настроены - то столько док-ции, что и идиот сможет создать любой процесс.

Намного сложнее заставить всех понять - что по ним надо работать (в основном - кастомера), и самый высший пилотаж - это суметь работать по любым процессам независимо от всех приколов с ресурсами, руководством, кастомером и т.д., т.е. по принципу "QA must go on" (только не надо мне говорить про "уволиться" :)) на таких проектах.
  • 0

#10 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 15 ноября 2006 - 10:26

Ох... Я вижу Вам пора писать свои публикации. :-) Это уже напоминает переписку в двух томах. :focus:

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

Слава,
спасибо за комменты,

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

И в такой ситуации уже как бы все равно - почему так случилось - надо либо делать, либо действительно увольняться. Какая мне разница, что ко мне подойдет мой руководитель и будет мне долго и нудно объяснять, почему так произошло, но если такой проект у меня уже на руках и я принял решение с ним работать - то тут уже интереснее - что же я с ним могу сделать.

Просмотр сообщения


1. Если долго и нудно - значит плохой начальник.
2. Если Вас это не интересует - значит вы теряете очень много в своей жизни.

Небольшой коммент по фразе:

Просмотр сообщения


Страшно представить Ваш основательный коммент. :good:


"... Я же описал ситуацию, когда "А потому что сразу не продумали, или еще хуже, не захотели тратить времени и средств" - это типичная проблема везде, когда берешься не за свое дело, а если, при этом, нет желания его делать, то результаты прогнозируемы и очевидны."

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

Просмотр сообщения


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

В основном мы получали такие проекты в моменты кризисов, когда уже не приходилось выбирать и не было возможности диктовать свои условия.

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

Просмотр сообщения


"подкалываю" - сочтемся. :ok:
Вас не удивляет почему, время от времени, люди приходят на этот самый форум с вопросами "как мне сделать то что заведомо не делается" ил "как мне спрогнозировать работы если нету ничего кроме билда?" или просто излить душу. Потому что не спрашивают, а почему так происходит. Потому что просто сидят и делают. А когда поднимают голову, то видят что они уже не по уши в болоте а, пару метров под уровнем поверхности. Иногда в этом винят руководство, хотя САМИ НЕ ЛУЧШЕ, иногда посыпая голову пеплом сидят и работают по 12-14 часов. Зачем? Вы можете ответить? Но главное не это. Главное почему так произошло. Почему берется проект и делается без процессов, с недостатком ресурсов, с урезанным бюджетом. В надежде на идейных работников?
На счет "нетипичен" - иногда жаль... Я не призываю всех увольняться. Если Вы сразу не наладили нормальную работу, потому что Вам не дают это сделать, тогда надо что-то менять. Либо работу либо мировоззрение. :crazy: Если поменяли второе, тогда никогда не кричите что начальник тупой или жадный.

Если не трудно - поделитесь опытом (я больше чем уверен, что у Вас тоже были такие проекты) - как Вы выходили из таких ситуаций ? Это не "вопрос-подколка". Мне действительно интересно знать - как в условиях кризиса ресурсов (не важно, по каким причинам) можно выйти из подобных ситуаций ?

Есть достаточно много публикаций по менеджменту в кризисных ситуациях, но они какие-то абстрактные - общие фразы только. Если есть возможность, не могли бы Вы или может еще кто-то, кто читает эту ветку просто кратко расписать - что же я буду делать как QA Manager на таком проекте.

Просмотр сообщения


На мой взгляд стоит открыть отдельную тему. В двух словах есть задача и есть реальность. Если они не сопоставимы то надо что-то менять. Это простая трейд-офф модель (модель по согласованию основных параметров). 1. Время, 2. Объем, 3. Ресурсы. Если что-то не вписывается, то ПРЯМО влияет на остальные два параметра. Вот с ними и играйтесь. Нет нужного времени - увеличивайте ресурсы или уменьшайте объем. И на оборот.


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

Просмотр сообщения


Зачем вам иметь мануал по которому "может быть" получится?


Я пока не смог определиться в области (как я себе ее сам называю) экстремального тестинга.

По процессам работать легко, особенно если они настроены, а даже если они и не настроены - то столько док-ции, что и идиот сможет создать любой процесс.

Намного сложнее заставить всех понять - что по ним надо работать (в основном - кастомера), и самый высший пилотаж - это суметь работать по любым процессам независимо от всех приколов с ресурсами, руководством, кастомером и т.д., т.е. по принципу "QA must go on"  (только не надо мне говорить про "уволиться" :)) на таких проектах.

Просмотр сообщения


И даже не собираюсь Вам говорить про увольнение (хоть и чувствую еще один подкол :acute: ).
Нельзя быть независимым от приколов. Надо уметь занамться tailoring (tailor - приспосабливать для определенной цели, в нашем случае подстраивание процесса под нужды и особенности проекта)
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#11 natEn

natEn

    Новый участник

  • Members
  • Pip
  • 67 сообщений
  • ФИО:Natalya

Отправлено 15 ноября 2006 - 11:27

Полностью согласна с chuk. Проблема в конечном счёте - это задача, которую надо решить. Позавчера был сдан проект: аналитическая система, конверторы xml-excel-mdf-html-etc, 45 видов входных файлов данных, OLAP, веб и вининтерфейсы (два - с активиксом и без).
С момента поступления ТЗ прошло менее полутора месяцев. Почти не верила, что справимся.
  • 0

#12 shisha_hwguy

shisha_hwguy

    Новый участник

  • Members
  • Pip
  • 23 сообщений
  • Город:Saint Petersburg

Отправлено 06 декабря 2006 - 11:57

Есть еще проблема встраивания тестирования в уже идущий проект. Когда все начиналось о тестировании особо не думали, т.к. ресурсов было мало.
В итоге много сил времени надо тратить на адаптацию проекта к тестированию.

Про планирование времени.
Здесь одна из самых серьезных проблем (на мой взгляд) это крайняя зависимость от других отделов. Практически любая задержка сказывается на сроках начала тестирования. При этом дату завершения никто сдвигать обычно не дает. Действительно единственных выход, это делать меньше но лучше. Т.е. оставлять какие-то компоненты без внимания уведомив об этом решении.
  • 0

#13 Yury

Yury

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Yury

Отправлено 06 декабря 2006 - 17:27

Публикация компании QAExpert.

Непрофессиональные проблемы тестирования в постсоветском государстве
Автор: Ростислав Борук

А почему речь идет о "Пост-советском государстве"?
В этой статье я не нашел ничего такого, чего не было бы на западе. :hi:
  • 0

#14 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 08 декабря 2006 - 16:19

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

Просмотр сообщения


Хотелось бы понять причину вопроса. :ok:

Я работал с западными компаниями, как со стартапами так и мировыми лидерами с ревеню больше миллиарда долларов в год. Не могу сказать что бы я обнаружил те-же источники проблем. Там считают деньги намного аккуратнее чем у нас. И не пускают "козлов" в огороды. :focus:
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#15 Yury

Yury

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Yury

Отправлено 09 декабря 2006 - 03:35

Я работал с западными компаниями, как со стартапами так и мировыми лидерами с ревеню больше миллиарда долларов в год. Не могу сказать что бы я обнаружил те-же источники проблем. Там считают деньги намного аккуратнее чем у нас. И не пускают "козлов" в огороды.  :focus:

Завидую я Вам. Хорошо быть идеалистом и верить, что на Западе всё лучше.

Кстати, Борис Байзер написал в одной из своих книг:
"Очевидно, что в СССР процес разработки программ существенно отличается от западного варианта" (цитирую по памяти книгу, которую прочитал много лет назад).

Как оказалось, что он на самом деле так совсем не думал.
Просто он обиделся за то, что его книги переводили в СССР без его разрешения, и надеялся на то, что эту книгу с таким антисовестким высказыванием переводить не будут. :ok:
Такой же был наивный человек, как и Вы.
  • 0

#16 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 09 декабря 2006 - 21:54

Завидую я Вам. Хорошо быть идеалистом и верить, что на Западе всё лучше.

Кстати, Борис Байзер написал в одной из своих книг:
"Очевидно, что в СССР процес разработки программ существенно отличается от западного варианта" (цитирую по памяти книгу, которую прочитал много лет назад).

Как оказалось, что он на самом деле так совсем не думал.
Просто он обиделся за то, что его книги переводили в СССР без его разрешения, и надеялся на то, что эту книгу с таким антисовестким высказыванием переводить не будут. :crazy:
Такой же был наивный человек, как и Вы.

Просмотр сообщения


Я даже не предполагал что могу показаться идеалистом. На самом деле - спасибо. Буду смотреть теперь еще и с этой стороны.
Отвечу просто - я не из тех кто пропагандирует Запад и запросто готов уехать из родного сердцу города.

Если не секрет, Борис Байзер сам признался (по ходу обсуждения вопрос: перевод книг без разрешения, так-же типичная практика на Западе или все таки там с этим лучше?)? :ok:

И все-таки, откуда корень вопроса? Есть ваше мнение "на Западе все то-же" - не согласен, хотя это не есть тема статьи, или Вы просто хотите обсудить что там не лучше - это уже другой вопрос. :focus:
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#17 Yury

Yury

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Yury

Отправлено 10 декабря 2006 - 05:07

И все-таки, откуда корень вопроса? Есть ваше мнение "на Западе все то-же" - не согласен

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

Я никогда не утверждал, что "на Западе все то-же". В разных западных организациях разные процессы разработки. В одних организациях процессы лучше, :focus: а в других хуже. :ok:
  • 0

#18 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 10 декабря 2006 - 10:41

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

Я никогда не утверждал, что "на Западе все то-же". В разных западных организациях разные процессы разработки. В одних организациях процессы лучше, :focus: а в других хуже. :ok:

Просмотр сообщения


Я полностью с Вами согласен, что там то-же не все гладко, и не собираюсь даже спорить. Однако, на мой взгляд, культура работы у нас, здесь, еще не достаточно высоко развита. Не многие стараются развивать. Большинство старается разбогатеть на "откате" или просто сорвать денег, а там уже как пойдет. Отсюда и различные компании: в которых не думают о людях; не выплачивают положенные компенсации; не ориентированы на качественный продукт. А в таких организация вырастают соответствующие специалисты. Все же у нас это выражено намного четче и очевиднее.

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

И как результат хотел бы отметить, что я не старался сравнивать наши компании с Западными. Это тоже не очень корректно, все таки мы живем в разных экономических и политических окружениях. Я исходил из наших реалий и возможностей.
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#19 Yury

Yury

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Yury

Отправлено 10 декабря 2006 - 16:52

Я полностью с Вами согласен, что там то-же не все гладко, и не собираюсь даже спорить.

Я тоже полностью с Вами согласен.


Однако, на мой взгляд, культура работы у нас, здесь, еще не достаточно высоко развита. Не многие стараются развивать. Большинство старается разбогатеть на "откате" или просто сорвать денег, а там уже как пойдет. Отсюда и различные компании: в которых не думают о людях; не выплачивают положенные компенсации; не ориентированы на качественный продукт.

Я боюсь, что Вы всё-же смотрите на Запад через розовые очки. Всё, о чём Вы пишете в этой цитате, характерно и для Запада.
Представляете, как заманчиво получить правительственный контракт на несколько сотен миллионов долларов и сколько денег при этом можно израсходовать на взятки?
А как Вы думаете в американских стартапах относятся к рядовым программистам, когда отцы основатели спят и видят себя как новых Билла Гейтса или Сергея Брина?


Еще хотелось бы отметить, что у нас, о человеке не думают либо вообще, либо перестают на начальных стадиях.

Ну это вопрос философский.
И там и тут о человеке заботятся в основном потому, что боятся его потерять.


И такие вещи как соц. пакет, мед. страховка, нормальное рабочее место и кухня с фруктами уже довольно давно стали нормой жизни компании.

А не могли бы Вы дать определения "соц. пакета", "мед. страховки" и "нормального рабочего места"?
Всё это очень сильно разное в разных фирмах.

Является ли для Вас нормальным рабочим местом кубик?
А как Вам нравится "открытая концепция" (Open concept), когда Вы видите и слышите всех коллег в достаточно большом зале?
А что Вы скажете по поводу "общего размещения" (Shared accomodation), когда у Вас нет даже своего стола и Вы должны его зарезервировать на день или на несколько недель, не зная, кто будет Вашим соседом? В этом случае у Вас даже нет места для бумаг и Вы должны их уносить домой каждый день вместе с лэптопом.

Кухня с фруктами это скорее исключение.
Правилом является только наличие кофе - чаще бесплатно, хотя иногда и за деньги (от доллара с небольшим за стаканчик кофе в коммерческом кофетерии до 25 сентов за чашку, когды рабочие сами его покупают в складчину, а компания предоставляет кофеварку). :focus:

П.С. Как мне кажется у нас достаточно сходное понимание. Я только хотел привести некоторые примеры того, что и на Западе, не всё так хорошо. :ok:
  • 0

#20 Yatagan

Yatagan

    Новый участник

  • Members
  • Pip
  • 2 сообщений

Отправлено 18 июня 2007 - 13:33

Статья содержит много орфографических и грамматических ошибок. Что сразу насторожило о качестве материала. После прочтения опасения подтвердились (IMHO конечно).
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных