Сочинение На Тему Кто Где Когда Зачем
Сочинение На Тему Кто Где Когда Зачем
Navigation
Recent Entries
Archive
Friends
Profile
Memories
This page
Previous Entry
Next Entry
Вдогонку у дискуссии о "хорошем списке задач" у Maxim Dorofeev . На мой взгляд, нет смысла применять какие-либо методики управления задачами, не имея элементарного навыка ставить сами задачи. И именно этой части уделяется наименьшее внимани е. Как это делать? 1) Хорошим принципом, знать и уметь применять который необходимо, является 5W (Что, кто, где, когда, зачем). В идеале - иметь навык формулировать mission statement для задачи в виде одного предложения, отвечающего на все 5 вопросов. http://en.wikipedia.org/wiki/Five_Ws В википедии об этом не сказано, однако, 5W также является основной техники приказов, используемой US Marine Corps. 2) Второй полезный навык - уметь формулировать секцию "что" развернуто, в виде списка критериев (чеклиста) наступления момента завершения задачи, допускающих простую проверку. Как я проверю, что задача завершена? Я вообще это сделать могу, это возможно? "Весь код уже написан, осталось только отладить" - это хороший критерий? Все остальное от лукавого. Включая S.M.A.R.T. Они автоматически получаются SMART, если следовать двум простым правилам выше. "Фичи", юзер-стори, и юз-кейсы - не от лукавого, а вполне годные. Это более специфичные для софта способы выразить секцию "Что", иногда вместе с "зачем", и рядом других вопросов (Фичлист, как правило, получается автоматически при выполнении пункта 2). И вот вам картинка на память - о 5W. Сам придумал. Она какбэ должна намекнуть, что процесс планирования (и формулировки задач) - довольно сложный problem-solving process, имеющий мало общего с рисованием гант-чартов в MS Project. Ошибки в котором обходятся дорого. Успехов. И чуть не забыл - не начинайте задачу с глаголов. В них нет ничего ни полезного, ни интересного.
Ух ты, пост! Не зря я подписался на этот журнал по RSS :-) Первый! :-)
Спасибо, как всегда хорошее резюме, упер к себе во внутреннюю вики, если не возражаете
Пользователь abayda сослался на вашу запись в записи « Про постановку задач » в контексте: [...] http://gaperton.livejournal.com/63676.html [...]
унести к себе и перевести на английский можно? и ссылку на оригинал в каком формате?
Да, конечно. Ссылку на оригинал в виде ссылки и указания имени.
Пользователь inandout_oflove сослался на вашу запись в записи « Кто, что, где, когда, зачем » в контексте: [...] Оригинал взят у в Кто, что, где, когда, зачем [...]
А интересно, как бы Вы по-русски (и не применительно к ИТ) назвали Design?
"Тактика". Ну, раз выше - стратегия.
Design - паршивое название. Но на момент рисования ничего лучше навскидку не придумал.
Здравствуйте! В нашей компании "ГОСТовский стиль управления проектами" является обязательным. Хотелось бы пообщаться с Вами, обменяться мнениями и, может быть, найти точки соприкосновения для сотрудничества. В силу конфиденциального характера проектов нет возможности обсуждать их в ЖЖ. Если это не противоречит Вашим принципам, оставьте свои координаты для связи в моей почте vandrosov@npomis.ru. Я постараюсь сообщить подробности. С уважением, Владислав.
Здравствуйте. И чуть не забыл - не начинайте задачу с глаголов. В них нет ничего ни полезного, ни интересного. А что плохого в глаголах? Не начитать subject с глаголов или описание? Посоветуйте, пожалуйста, хорошие мануалы / книги / видео по грамотному созданию и формулированию задач. Спасибо.
С глаголами две проблемы. - избыточность и неинформативность. "Разработать..." "Сделать..." "Ускорить..." "Реализовать...". У многих задач одно и тоже слово в начале. Полезной информации оно не несет. Но создает своим присутствием иллюзию, что о задаче что-то сказано. А оно и так понятно, что задачу надо "сделать". Лишнее. - Смещение фокуса внимания с результата на процесс. Это хорошо заметно при наблюдении за мучениями людей, когда они пытаются заполнить шаблон советского ТЗ. "Целью данной работы является разработка..." Но постойте. Слова не игрушки, они несут смысл. А если не несут, то нехрен ими сорить. Если это в самом деле правда, что целью данной работы является сам процесс работы, как таковой - может, не стоит эту работу вообще проводить? Она _зачем_ нужна? Каков ее результат? Прекрасно осознавая, что начинать название задачи с глагола - интуитивно понятно, и так делает большинство, я предпочитаю вместо этого характеризовать ее результат. Что есть результат? Для софта, как примеры: - Название фичи, которая формулируется как то, что может пользователь сделать посредством системы. То есть, действие _пользователя_, не программиста. - User Story, что примерно то же самое, в википедии прекрасная статья. - Use case - сценарий использования системы, который будет работать в результате завершения задачи. Общее правило - название задачи должно давать представление о предназначении ее результата, характеризуя _цели_ работы, а не ее _задачи_. Несет информацию о предназначении результатов, а не о том, что исполнитель собирается делать в процессе. Начиная с глагола, вы скорее всего (не обязательно, но скорее) склонны думать о том самом процессе. Это то, к чему человек по природе склонен. И это одна их тех склонностей, что мешает. Поэтому, мы запрещаем глаголы в названиях задач. И, принимая во внимание вышесказанное как руководство, видим немедленный результат. Edited at 2014-06-12 09:58 pm (UTC)
Троллейбус как национальный бренд России
Recommend this entry
Has been recommended
Send news
Кто, что, где , когда , зачем - Gaperton's blog — LiveJournal
Ответы Mail.ru: сочинение на тему "Что? Где ? Когда ?
Что? Где ? Когда ? Зачем ? Почему ? | Яндекс Дзен
Сочинение на тему : “ Почему ?” 👍 | Школьные сочинения
Сочинения -рассуждения на тему : "Для чего живёт человек?"
Сочинение Образование И Воспитание
Монтаж И Наладка Оборудования Реферат
Изображение Пространственных Фигур Реферат
Сочинение Памятники Культуры В Своем Родном Крае
Сочинение Подвиг Евпатия Коловрата Небольшое