вторник, 31 января 2012 г.

Lesson 69

Хором повторяем мантру: У нас самый замечательный офис и все остальные офисы завидуют нам!

Не, ну серьезно. Особенно радует pivpav утренними шаржами с возможностью их дополнить и улучшить.

Пруфпик:
Альбом: office


Слово Канеру:

Сообщайте о ошибках проектирования.

ПО создает ценность для людей. Это задача ПО. Программа — часть системы, включающей оборудование, другие программы и людей. ПО имеет меньшую ценность, если оно сложно в использовании, запутано, несовместимо с другими программами или завязано на узкий диапазон железа. Может быть, вы единственный член команды разработки, кто смог увидеть и оценить ошибки проектирования и то, как они повлияют на работу системы. Если вы не зарепортите эти проблемы, то кто?

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

О запоздалой критике проектирования Даже если продукт был полностью спроектирован заранее (что маловероятно в реальных условиях реального мира), люди не полностью видят систему до тех пор, пока она не будет создана. Это вполне нормально для людей — понимать, что система неверно спроектирована, только после начала работы с ней. О проблемах нужно сообщать, когда они обнаружены, и многие из них не будут найдены до тех пор, пока система не будет почти закончена.

О проблемах с экспертизой Действительно, тестировщики отличаются по своей способности понимать и оценивать вопросы проектирования. С другой стороны тестировщики это те люди, которые сопровождают система через все этапы до продажи ПО или его запуска в производство. Exercise some caution if you don't have relevant expertise. Например, перед критикой пользовательского интерфейса, стоит почитать документацию системы и пообщаться с другими людьми, которые знают о проектировании больше вас. Но если вы уверены, что проблема есть — занесите ее в багтрекер.

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

Примечания
- Именно поэтому мы видим большой интерес к таким современным подходам, как XP и RUP (более общее — итеративный, адаптивный, эволюционный, гибкий подходы ). Эти подходы принимают как данность то, что изменения требований к продукту появятся и стремятся минимизировать риски этих изменений. См. например Beck 1999, Kruchten 2000, and http://www.agilealliance.org.
- Apple, Microsoft, Sun и многие другие публиковали руководящие принципы разработки пользовательского интерфейса.
- Не всегда возможно сформировать правильный набор людей в контрольной группе в срок. Возможно, вам придется работать со сторонними консультантами или провести обучение персонала или для выполнения некоторых видов оценок.

Там внутри я так и не перевел одно предложение, реквестирую подсказки.

10 комментариев:

  1. Угу, я вообще удивляюсь на народ. Каждый день - новый.
    Вот намедни была жесть... утром был нарисован просто забор, да...

    ОтветитьУдалить
  2. дальше стали рисовать уже на заборе?)))))))

    ОтветитьУдалить
  3. ох, юзеры... а точнее, ещё хуже - юзерши! - это нечто.
    сегодня рассказ одного вернувшегося из командировки соратника. тётка (юзер):
    - у вас ничо не работает, даже включать не буду!
    сотрудник:
    - что конкретно не работает?
    - а ничо не работает!
    - давайте посмотрим.
    тётка неохотно включает машину. махает где-то вдалеке от неё карточкой доступа.
    - вот видите - не работает!
    сотрудник:
    - а вы поднесите карточку к считывателю.
    тётка с недоверием: оно не будет работать... вжик! заработало.
    тётка:
    - ну, всё равно оно дальше не будет работать!
    сотрудник:
    - вводите пароль доступа. сейчас посмотрим, что за проблема...
    в общем, препирательство с тёткой длилось долго. при этом при малейшем непонимании работы она тупо вырубала машине питание и заявляла "ничо не работает, я пошла отсюда".
    война продолжалась целый день. тётка подносила карточку куда попало, кроме считывателя, вводила неверные пароли, совала в машину листы вверх ногами и прочее, и прочее. и при этом истерила "ничо не работает! вот видите - ничо не работает!".
    и вот как с такими юзерами работать? я бы убила на месте.

    ОтветитьУдалить
  4. Все ходы записывать не свою работу - не делать, будет бузить - эскалировать. И все вежливо. Ни в коем случае не подкалывать и не мстить.
    Ну а совсем припечет- начать все делать по инструкции...
    Эх, техподдержка... хотя мне попадались в основном нормальные люди, которых можно понять.

    Хотя убить наверняка дешевле, да.

    ОтветитьУдалить
  5. у меня никогда не хватало терпения на юзеров. на моей первой работе, где мне приходилось иметь с ними дело, меня прозвали "Кровавый Топор". за особую щепетильность.

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

    ОтветитьУдалить
  7. Ага, нужен большой плакат: Думай, блядь, заранее!
    Два на метр...

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

    ОтветитьУдалить