Чорт! Совершенно не понимаю как у других хватает времени так много и красиво писать в блогах.
В ИТ с конца 90-х прошлого века. Сейчас занимаюсь внедрением систем в одном очень-очень большом федеральном заказчике -) Этот блог создан для записи моих идей, случаев из моей практики проектирования и внедрения ИТ систем, в первую очередь по ITSM. Систем мониторинга и управления ИТ, инфраструктурных проектов и, конечно же, об управлении командой, проектом, заказчиком.
Ярлыки
- ГОСТ34 (14)
- книги (3)
- коллеги (1)
- Коммуникации (6)
- менеджмент (21)
- мониторинг (3)
- правила (8)
- просто (1)
- размышлизмы (4)
- Рекомендации (1)
- ресурсы (3)
- ТРП (10)
- трюки (1)
- шутки (1)
- Tools (8)
понедельник, 31 октября 2011 г.
вторник, 11 октября 2011 г.
Как удержать в голове структуру документов
Как удержать в голове требуемую структуру документов?
Например требования к структуре ТЗ, ПД и других ДДЗ?
В самом простом пакете документов которые мы передаем заказчику содержится около 12 документов. Хорошо если я более менее помню ГОСт. Но структура может меняться. И забываться.
В качестве справочника я использую вот что:
Ну если есть желание могу поделится исходниками -)
Например требования к структуре ТЗ, ПД и других ДДЗ?
В самом простом пакете документов которые мы передаем заказчику содержится около 12 документов. Хорошо если я более менее помню ГОСт. Но структура может меняться. И забываться.
В качестве справочника я использую вот что:
- перевел в формат мозговой карты РД50
- распечатал в формате "один документ - один лист"
- переплел в альбом и постоянно держу под рукой
Ну если есть желание могу поделится исходниками -)
ТРП - Структурная схема системы
С чего мы начинаем выбор квартиры - с двух схем: 1) Карты района; 2) Плана квартиры.
А сколько типов схем вы используете для иллюстрации примененных или предлагаемых технических решений?
Я использую всего 3. А видел много -). Итак:
Структурная схема
А сколько типов схем вы используете для иллюстрации примененных или предлагаемых технических решений?
Я использую всего 3. А видел много -). Итак:
- Структурная схема
- Функциональная схема (расскажу позже)
- Схема автоматизации бизнес\технологического процесса (если он есть) (аналогично)
Структурная схема
Я не считаю, что Джобс был иноватором и, что тем более, он изменил мир.
ай-фон и ай-пад не изменили мир, они ничего не принесли в мир нового.
Просто качественно улучшенные для массового пользователя бытовые устройства. И все. Ничего более.
Если сейчас отобрать у всех их пленшетики - ничего не изменится.
Вот Гейтс изменил мир, а Джобс - нет.
Хотя, может время покажет, и окажется, что Джобс то же приложил руки к изменению мира, но не в приборчиках на которые все молятся, а на саму идею "юзабилити в квадрате".
Может быть воодушевленные успехом Джобса, топ менеджеры поймут простую идею - подавляющее удобство использования стоит пары лет работы и потраченных денег. Может быть они перестанут делать УГ?
ай-фон и ай-пад не изменили мир, они ничего не принесли в мир нового.
Просто качественно улучшенные для массового пользователя бытовые устройства. И все. Ничего более.
Если сейчас отобрать у всех их пленшетики - ничего не изменится.
Вот Гейтс изменил мир, а Джобс - нет.
Хотя, может время покажет, и окажется, что Джобс то же приложил руки к изменению мира, но не в приборчиках на которые все молятся, а на саму идею "юзабилити в квадрате".
Может быть воодушевленные успехом Джобса, топ менеджеры поймут простую идею - подавляющее удобство использования стоит пары лет работы и потраченных денег. Может быть они перестанут делать УГ?
Правила хорошего документа
Что отличает правильно написанный тех документ?
То же что и выступление хорошего политика - яркость, лаконичность, простота.
(рекомендую к прочтению - Карстен Бредемайер "Черная риторика", Альпина паблишер".
Не менее 2/3 разговорных приемов можно и нужно использовать при подготовке документов)
Итак хороший документ должен быть:
1. Гармоничным. Хорошая и понятная структура изложения. Четкая рубрикация. Информация должна быть там "где ее ожидают".
2. Четкие и ясные формулировки. По крайней мере основные положения проектного документа должны быть сформулированы так, чтобы не понять или понять их неправильно не представлялось возможным. Формулировки должны быть настолько простыми, чтобы врезатся в память.
3. Делайте "паузы" в документах. Разбивайте документ на разделы. Абзац не больше 10 строк. Раздел не больше 3-5-и страниц. Если в разделе должна быть большая спецификация, код, таблица - отправьте в приложение.
4. Тщательно взвешивайте необходимость объяснений и комментариев. Изложенные проектные факты будут выглядеть менее убедительно и более сложны для понимания, если вы будете описывать их во всех деталях. Если же описать детали надо, то изложите факты, а потом их детализируйте. Или переносите их в другие документы и приложения, специально для этих целей предназначенные.
5. Фокусируйте внимание читателя на основных положениях документа, не разбавляйте их пустопорожним описанием. Или следуйте п.4
6. Обязательно включайте в текст описание технических терминов которые вы используете.
7. Откажитесь от льстивых замечаний в адрес читателя. Особенно в различного рода обоснованиях и коммерческих предложениях.
8. Лучше меньше, да лучше. Обилие аргументов не нужно. Обилие доказательств не нужно. Обилие описаний и деталей не нужно. Не нужно и наличие нескольких вариантов работы.
То же что и выступление хорошего политика - яркость, лаконичность, простота.
(рекомендую к прочтению - Карстен Бредемайер "Черная риторика", Альпина паблишер".
Не менее 2/3 разговорных приемов можно и нужно использовать при подготовке документов)
Итак хороший документ должен быть:
1. Гармоничным. Хорошая и понятная структура изложения. Четкая рубрикация. Информация должна быть там "где ее ожидают".
2. Четкие и ясные формулировки. По крайней мере основные положения проектного документа должны быть сформулированы так, чтобы не понять или понять их неправильно не представлялось возможным. Формулировки должны быть настолько простыми, чтобы врезатся в память.
3. Делайте "паузы" в документах. Разбивайте документ на разделы. Абзац не больше 10 строк. Раздел не больше 3-5-и страниц. Если в разделе должна быть большая спецификация, код, таблица - отправьте в приложение.
4. Тщательно взвешивайте необходимость объяснений и комментариев. Изложенные проектные факты будут выглядеть менее убедительно и более сложны для понимания, если вы будете описывать их во всех деталях. Если же описать детали надо, то изложите факты, а потом их детализируйте. Или переносите их в другие документы и приложения, специально для этих целей предназначенные.
5. Фокусируйте внимание читателя на основных положениях документа, не разбавляйте их пустопорожним описанием. Или следуйте п.4
6. Обязательно включайте в текст описание технических терминов которые вы используете.
7. Откажитесь от льстивых замечаний в адрес читателя. Особенно в различного рода обоснованиях и коммерческих предложениях.
8. Лучше меньше, да лучше. Обилие аргументов не нужно. Обилие доказательств не нужно. Обилие описаний и деталей не нужно. Не нужно и наличие нескольких вариантов работы.
Подписаться на:
Сообщения (Atom)