ПОХОД

Собрались сходить в легкий поход по Крыму. По этому поводу полезная информация для участников:

 

ОДЕЖДА

Обязательный комплект:

1. Кроссовки/ботинки "ходовые"
2. Брюки "ходовые"
3. Носки "ходовые" 2-3-4 пары (дело личной гигиены)
4. Свитер/флис "ходовой"
5. Ветровка (желательно хотя бы с минимальными водоотталкивающими свойствами, чтобы при маленьком дождике не водружать на себя парилку из дождевика)
6. Шапка (флис/шерсть)
7. Белье "ходовое" 2-3-4 комплекта (опять же дело личной гигиены)
8. Обувь "стояночная" (хоть тапки)
9. Брюки "стояночные"
10. Свитер/флис "стояночный"
11. Белье "стояночное" (ну, вы знаете)
12. Дождевик (если пленка - штуки 3 на случай порчи)
13. Теплые (шерстяные) носки для сна

Опциональный комплект:

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

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

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

если вы не пользуетесь термобельем, то лучше взять столько сменных комплектов белья, сколько будет переходов

СНАРЯГА

Обязательный комплект:

1. рюкзак (по-идее литров 60 должно хватить с запасом, в 80 войдет весь скарб с верхней одеждой и карематами :)
думаю, девушкам хватит рюкзака на 40, если его хорошенько обвесить карематом, спальником и ветровкой, остальное влезет внутрь
2. непромокаемый чехол для рюкзака
3. каремат
4. спальник (с температурой комфорта 0-10 градусов примерно)
5. миска, ложка, кружка
6. туалетная бумага
7. место в палатке :)
8. предметы личной гигиены: зуб. паста, щетка, мыло и т.п. (можно брать расходники на несколько человек)

Опциональный комплект:

9. попа
10. палки
11. налобный фонарь (практически обязательный реквизит)

ЕДА

Меню (на человека):

1-й день

завтрак - в поезде чем бог пошлет

перекус:
Колбаса копченая - 60гр
Сухари - 15
Щербет - 50
Сухофрукты - 50
Печенье - 50

Ужин:
макароны - 80
Тушенка - 30
Масло - 15
Сухари - 15
Кетчуп - 5
Чай
Сахар - 50

2-й день

Завтрак:
Гречка - 80
Тушенка - 30
Масло - 15
Сухари - 15
Чай
Сахар - 50
Конфеты - 30
Печенье - 50

Перекус:
Корейка - 60
Сухари - 15
Халва - 50
Сухофрукты - 50
Пряники - 50

Ужин:
Картофель тушеный - 80
Тушенка - 30
Огурцы соленые - 50
Спирт - 100
Сухари - 15
Чай
Сахар - 50

3-й день

Завтрак:
Пшенка - 80
Сыр - 30 (типа баноша получится)
Масло - 15
Сухари - 15
Чай
Сахар - 50
Конфеты - 30
Вафли - 50

Перекус:
Сало - 50
Сухари - 15
Козинаки - 50
Сухофрукты - 50
Баранки - 50

Ужин:
Рис - 80
Рыбные консервы - 30
Сухари - 15
Огурцы соленые - 50
Спирт - 100
Чай
Сахар - 50
Вафли - 50

4-й день
завтрак
повторим меню второго дня
дальше - покупаем подножное
чипсы/пиво

Документы, с которыми мы работаем

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

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

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

Какую имеем проблему: все эти варианты использования предполагают разные формы представления информации, а мы пользуемся одной. Если посмотреть на любой (не побоюсь этого слова) процесс, то окажется, что между клиентом и девелопером информация меняет свое представление как минимум один раз (даже в ХР, где представитель заказчика с требованиями в голове чуть ли не спит со своими девелоперами). И это не спроста! Давно известно, что заказчик и исполнитель по-разному видят разрабатываемый продукт, и поделать с этим ничего нельзя. Задача аналитика как раз и состоит в том, чтобы связать эти два лагеря и при этом обеспечить минимальные потери при передаче информации. Если совсем уж обобщить, то можно представить весь процесс разработки, как работу по превращению мыслей клиента в код с учетом ограничений внешней среды. Задача всех участников при этом - не давать информации теряться и искажаться, насколько это возможно. И аналитик - дирижер этого оркестра, следящий за чистотой звука всех инструментов.

Что в на входе? Разработчики хотят подробностей реализации. Заказчик тоже гораздо охотнее делится своими соображениями по поводу отдельных формочек и кнопочек, чем глобальным видением продукта. А многие этого видения просто не имеют, поскольку начинают бизнес “по образу и подобию”, не представляя зачастую всей бизнес-модели. Им кажется, что взяв сайт “как у Васи” и улучшив “ту кнопочку” и “эту формочку”, они тут же вырвутся вперед Васи и вобще планеты всей. Да и зачем разработчикам знать, откуда ноги растут? Клиент ведь уже знает все формочки и кнопочки, он все сам расскажет. Аналитик, поставленный в нужную позу этими двумя лагерями и подгоняемый жестким оценочным цейтнотом (где ваше предложение? мы уже получили миллион предложений от ваших конкурентов!), идет на поводу у обстоятельств и выдает документ с подробным списком формочек и описанием работы кнопочек на каждой из них, построенный на материалах допросов заказчкиа.

Что в результате? Во-первых у всех участников забега создается иллюзия полноты требований. Еще бы, ведь каждая кнопочка расписана! Благодаря этому заказчик считает, что анализ закончен, и очень удивляется необходимости в дальнейшем отвечать на вопросы. Благодаря этому же разработчик дает оценку, предполагая, что все требования уже устаканены и забывая, что нет ничего постоянного в этом мире. Во-вторых, когда приходит время обобщать и рисовать архитектуру, выясняется, что документ, прекрасно понимаемый в частях (в пределах описания одной формочки на паре страниц), совершенно не пригоден для понимания в целом. Выясняется, что для разработки архитектуры требуется несколько иная форма представления, а это требует дополнительного анализа, а времени уже нет: заказчик торопит, он уже хочет видеть те самые формочки, которые ему обещали. И, наконец, в четвертых! Самое главное! Читать медленно! Клиент склонен забывать о том, что он говорил, и, если у нас нет задокументированной концепции продукта, нам хана! Что будет стоить поменять положение кнопочки на форме? Или даже добавить кнопочку? Или перекрасить? А что будет стоить добавить новую роль, о которой клиент умолчал, потому что считал ее наличие само собой разумеющимся, или потому что забыл, но он ведь об этом не скажет. Или что будет стоить добавить/изменить целый процесс, который не был затронут (ведь, как правило, описание формочки затрагивает только часть процесса)? Это может вылиться с десятки формочек и сотни кнопочек! Причем я не утрирую!

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

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

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

Продолжение следует...