Управление проектами → ВНЕДРЕНИЕ «ПОД КЛЮЧ»: взаимопонимание сторон
Всем привет!
Приглашаю ознакомиться ERP-программистов, аналитиков и консультантов с тезисами, применение которых может:
— упростить процедуры выбора и внедрения ERP-системы для производственного предприятия
— наладить взаимопонимание при общении первых лиц со стороны заказчика с менеджерами проекта со стороны исполнителя и прийти к доверительным отношениям внутри команды проекта
— сэкономить время менеджеров своей организации и снизить свои затраты на проект
Под термином в названии статьи «внедрение «под ключ»» подразумевается поставка и внедрение ERP-системы в полном соответствии с ожиданиями и требованиями клиента.
Обосновывается утверждение, что для того, чтобы сделать проект по внедрению ИС успешным и быстрым, от заказчика, кроме понимания целей такого проекта, желания их достичь и ресурсов для их достижения, потребуется потратить много собственного времени на участие в каждом стадии проекта в качестве полноценного его участника. Для облегчения понимания проектов внедрения ИС заказчиком проведена аналогия между заказным программным обеспечением (ПО) и обычным изделием – ковром, который тоже можно изготовить по индивидуальному заказу.
Приглашаю ознакомиться ERP-программистов, аналитиков и консультантов с тезисами, применение которых может:
— упростить процедуры выбора и внедрения ERP-системы для производственного предприятия
— наладить взаимопонимание при общении первых лиц со стороны заказчика с менеджерами проекта со стороны исполнителя и прийти к доверительным отношениям внутри команды проекта
— сэкономить время менеджеров своей организации и снизить свои затраты на проект
Под термином в названии статьи «внедрение «под ключ»» подразумевается поставка и внедрение ERP-системы в полном соответствии с ожиданиями и требованиями клиента.
Обосновывается утверждение, что для того, чтобы сделать проект по внедрению ИС успешным и быстрым, от заказчика, кроме понимания целей такого проекта, желания их достичь и ресурсов для их достижения, потребуется потратить много собственного времени на участие в каждом стадии проекта в качестве полноценного его участника. Для облегчения понимания проектов внедрения ИС заказчиком проведена аналогия между заказным программным обеспечением (ПО) и обычным изделием – ковром, который тоже можно изготовить по индивидуальному заказу.
Управление проектами → Мой подход к созданию ТЗ на шаблонные сайты из песочницы
Вместо эпиграфа.
Поймал дед золотую рыбку. Она ему говорит:
— Чего тебе, дед?
— Хочу чтоб мой аппарат был длиной до колен.
Взяла рыбка и укоротила деду ноги.
Мораль: ставьте корректно техническое задание.
Добрый день великий и могучий Хабр.
Некоторое время назад было несколько постов о технических заданиях (Как поставить задачу для простого (шаблонного) сайта, Почему мы никогда не составляем ТЗ. А что взамен?, Правила технического задания), которые хотелось бы продолжить и рассказать про мой подход к написанию ТЗ на шаблонные сайты.
Управление проектами → Почему я не пишу ТЗ из песочницы
Конечно заголовок немного лукавый, т.к. по государственным контрактам практически всегда приходится разрабатывать техническое задание. Для государственных проектов ТЗ фактически необходимы:
1. Для проведения приемочных испытаний;
2. потому что так принято;
3. ИТ-проекты государство принимает по весу бумажных документов.
Для своих разработчиков я ТЗ (в общепринятом понимании) не составляю, т.к. банально нет времени составлять документ, в котором нужно в текстовом виде расписать функциональность создаваемого ПО. Второй причиной моей нелюбви к ТЗ является невозможность без привлечения программистов правильно и точно сформулировать требования к ПО. В тот момент, когда пишется ТЗ на новую разработку программисты работают над другим проектом, и отвлекать их — значит напороться на конфликты. Последней, но не менее важной, причиной отказа от ТЗ является желание не связывать руки разработчиков заранее навязанным решением. Вполне возможно, что программист найдет более оптимальное решение, если будет четко знать что от него хотят. Поэтому в процессе работы был выработан следующий подход формулировки заданий программистам.
1. Для проведения приемочных испытаний;
2. потому что так принято;
3. ИТ-проекты государство принимает по весу бумажных документов.
Для своих разработчиков я ТЗ (в общепринятом понимании) не составляю, т.к. банально нет времени составлять документ, в котором нужно в текстовом виде расписать функциональность создаваемого ПО. Второй причиной моей нелюбви к ТЗ является невозможность без привлечения программистов правильно и точно сформулировать требования к ПО. В тот момент, когда пишется ТЗ на новую разработку программисты работают над другим проектом, и отвлекать их — значит напороться на конфликты. Последней, но не менее важной, причиной отказа от ТЗ является желание не связывать руки разработчиков заранее навязанным решением. Вполне возможно, что программист найдет более оптимальное решение, если будет четко знать что от него хотят. Поэтому в процессе работы был выработан следующий подход формулировки заданий программистам.
Бизнес студии → Как поставить задачу для простого (шаблонного) сайта
За последнюю неделю-две мне довелось увидеть несколько опросников, которыми мучают своих клиентов всякие разные студии перед созданием простых шаблонных сайтов. Это чрезвычайно меня огорчило и навело на мысль предложить намного более эффективный и клиенто-ориентированный подход к постановке задачи и написания ТЗ для простых сайтов в условиях ограниченности времени и бюджета .
Помнится, кстати, что в комментариях к статьям о проектировании мне задавали такие вопросы вроде «А что делать, когда нет времени и денег на проектирование?». Ответ ниже.
Помнится, кстати, что в комментариях к статьям о проектировании мне задавали такие вопросы вроде «А что делать, когда нет времени и денег на проектирование?». Ответ ниже.
Блог компании Online-Pro → Пример техзадания на сайт. Сэкономит время и нервы
Сайт – всегда компромисс между разработчиком и владельцем, каждый из которых – профессионал в своей области.
Точек зрения на то, каким должен быть сайт, много: у программиста одна, у дизайнера – другая, у интернет-маркетолога – третья, у владельца…
На самом деле, точка зрения – всего одна – у конечного пользователя ресурса. И именно это в первую очередь нужно учитывать. Естественно, принимая во внимание удобство обслуживания сайта администратором.
В чем преимущества грамотно написанного технического задания:
Точек зрения на то, каким должен быть сайт, много: у программиста одна, у дизайнера – другая, у интернет-маркетолога – третья, у владельца…
На самом деле, точка зрения – всего одна – у конечного пользователя ресурса. И именно это в первую очередь нужно учитывать. Естественно, принимая во внимание удобство обслуживания сайта администратором.
В чем преимущества грамотно написанного технического задания:
- однозначное понимание всеми участниками проекта того, как и что должно работать
- экономия времени на разработке и всяческих уточнениях
- возможность еще до начала работы оценить сложность проекта и продумать тонкие моменты
- возможность после завершения работы отследить, все ли было сделано так, как задумывалось
- возможность рассчитать окончательную стоимость проекта до начала работы
- возможность распределить ответственности обеих сторон
Блог компании Digital Professionals Hub → Техническое задание: какие элементы должны быть прописаны, а какие – в уме
Когда мне предложили данную тему для написания своих мыслей в виде статьи, я долго думал, о чем же написать, потому что, по сути, вся данная статья укладывается в одно предложение, которое является прямым ответом на данный вопрос — Все документы должны быть прописаны и никаких моментов не должно быть в уме. Почему именно так? Рассмотрим по пунктам:
Персональные блоги → Рассуждения о проблемах технического задания
Ни для кого не секрет, что у компаний разработчиков сайтов есть проблемы в написании технических заданий. Этот топик — попытка взглянуть на основные проблемы, которые существуют в написании технических заданий.
Блог компании Webprojects → Трудности перевода или История одной иконки
«Если вы ученый, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан».
(Курт Воннегут)
Ave, habrahomines, morituri vos salutant. Идущие на смерть приветствуют хабрачеловечество.
Приготовьтесь к беспощадному поединку. Сегодня на горячем песке Колизея сойдутся в кровавой схватке менеджер и программист. Менеджер подобен ретиарию, вооруженному сетью, трезубцем и кинжалом. Программист – мирмиллион с наплечником, щитом и гладиусом.
Сие историческое сравнение всякий раз приходит почему-то на ум, когда речь заходит о формулировке так называемого технического задания, попросту ТЗ. Складывается полное ощущенье, что менеджер и программист говорят на разных языках, и один из них галл, а другой, предположим, фракиец.
Менеджера можно понять. Ему важно сдать работу в срок. Объяснить менеджеру, что для выполнения работы нужно несколько больше времени, чем он планировал, иногда трудно. Менеджер мыслит единицами времени, человеко-часами. У него нет видимых причин доплачивать сотруднику за сложность реализации.
Всякий программист в глубине души большой ребёнок. Он как доктор Хаус, которому разгадывать загадки гораздо интереснее, чем спасать человеческие жизни.
А загадки случаются. Порой – на самом простом месте.
(Курт Воннегут)
Ave, habrahomines, morituri vos salutant. Идущие на смерть приветствуют хабрачеловечество.
Приготовьтесь к беспощадному поединку. Сегодня на горячем песке Колизея сойдутся в кровавой схватке менеджер и программист. Менеджер подобен ретиарию, вооруженному сетью, трезубцем и кинжалом. Программист – мирмиллион с наплечником, щитом и гладиусом.
Сие историческое сравнение всякий раз приходит почему-то на ум, когда речь заходит о формулировке так называемого технического задания, попросту ТЗ. Складывается полное ощущенье, что менеджер и программист говорят на разных языках, и один из них галл, а другой, предположим, фракиец.
Менеджера можно понять. Ему важно сдать работу в срок. Объяснить менеджеру, что для выполнения работы нужно несколько больше времени, чем он планировал, иногда трудно. Менеджер мыслит единицами времени, человеко-часами. У него нет видимых причин доплачивать сотруднику за сложность реализации.
Всякий программист в глубине души большой ребёнок. Он как доктор Хаус, которому разгадывать загадки гораздо интереснее, чем спасать человеческие жизни.
А загадки случаются. Порой – на самом простом месте.
Бизнес студии → Типовой шаблон технического задания на разработку сайта
ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.
Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании.
Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.
Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании.
Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.
Персональные блоги → Кто проектирует сайты?
Поискав на Хабре материалы на тему проектирования и составления технических заданий, я обнаружил, что их очень немного, и те, которые есть, довольно поверхностны и содержат лишь ключевые рекомендации по производственному процессу…
Нет, слишком сложно начал. Люди, где примеры технических заданий? Где клёвые детальные прототипы? Где примеры решений задач с разработкой сложных сайтов, с различными ролями пользователей, с интерактивными приложениями? Где кейсы?
Нет, слишком сложно начал. Люди, где примеры технических заданий? Где клёвые детальные прототипы? Где примеры решений задач с разработкой сложных сайтов, с различными ролями пользователей, с интерактивными приложениями? Где кейсы?