Может это мое субъективное мнение, но мне как руководителю команд разработчиков, возможность детализировать задачи до любого уровня и раскладывать их на диаграмме Ганта очень сильно помогает планировать и контролировать реализацию проектов. Используя представление MS Project-а (или OpenProject) я могу видеть картину в целом.
А сравнение со строителями очень верное, более того, я считаю что в ИТ отрасли процент не успешных проектов можно значительно снизить используя технологии других отраслей, формирование которых происходило тысячелетиями (в т.ч. и строительства) и ничего зазорного здесь нет.
Еще забыл, для меня совершенно недостаточно плоского представления задач (Milestones & Tickets), хотелось бы иметь что-то вроде представления как в MS Project для планирования задач
Пользуемся assembla-ой уже около полугода, из недостатков:
— тормозит (для меня это самый большой недостаток), могли бы сделать хотя бы работу с Task-ами на Ajax-е чтобы не ждать каждый раз перезагрузки 'тяжелой' страницы
— возможности по управления правами доступа к SVN для одного Space-а очень ограничены (всего 3 варианта Read, Read/Write, Own)
— Wiki глючит
— множество просчетов с юзабилити, например чтобы вбить затраченное время в Time Tracking нельзя ввести время с клавиатуры, нужно кликать мышкой чтобы выставить минуты (1 клик — ± 1 минута)
— Стоит дорого
Из плюсов могу ответить надежность данного сервиса
Последнее время все чаще задумываюсь о том что нужно искать что-то другое
А я использую LinqToSql в большинстве своих проектов, и очень доволен его работой, а главное, предсказуемостью результата. Работал с EF, намучился ввиду большого числа ограничений и не оптимизированного SQL — поэтому отказался от его использования. NHibernate тоже пробовал. Отказался из-за слабой поддержки Linq-синтаксиса.
Прочитал все и задумался может я просто не программист, но таких ярко выраженных особенностей в себе не наблюдал. Хотя занимаюсь разработкой ПО уже порядка 10 лет. Правда я никогда не работал в крупных компаниях, возможно поэтому все стадии прошли для меня стороной и сохранился энтузиазм…
У меня были другие болезни — был ярым C++-шником долгое время, считал все остальное недоязыками. Сейчас конечно более взвешенно отношусь, и использую то что лучше подходит для конкретной задачи.
>> Кто вам кстати сказал, что ТЗ пишется юридическим языком? «резиновая» и «статичная» верстка — это уже зависит от дизайн-макета.
ТЗ пишется техническим языком, но при этом все термины должны быть расшифрованы чтобы избежать двусмысленностей и неверного тракования если не дай бог потребуется судебное разбирательство, в т.ч. и резиновая верстка, блочная верстка
По пункту 1.
Упоминая 'соответствовать стандарту w3c' нужно расшифровывать что это за организация, привести ее полное название, адрес сайта. Кроме того, xHTML какой версии? Еще было бы неплохо привести ссылку на сам стандарт.
Совершенно не согласен, это не шаблон, это общий план по которому потом можно написать ТЗ, сделать шаблонное (типовое) ТЗ. Возьмем например шаблон справки 2НДФЛ, в случае вашего понимания шаблона, она бы выглядела так:
1. Данные налоговой инспекции
2. Данные человека
3. Данные о доходах
4. Подпись и печать
Как вы думаете, с какого раза человек правильно бы заполнил справку 2НДФЛ по такому шаблону? А подумайте какой удар по кредитным учреждениям нанес бы такой шаблон?
Уважаемый Александр, к сожалению это не ТЗ, а лишь общий план. Большинство требований (например требования к верстке) совершенно не зависят от клиента, а их действительно сложно сформулировать юридически грамотным языком, т.к. в юр. плоскости понятия «резиновая» и «статичная» верстка не применимы.
Что касается общих пунктов которые не хватает в вашем плане это:
— «ограничения» создаваемого сайта по нагрузке, максимальному кол-ву страниц, хостингу (требования к хостингу) и т.п.
— оговорки о том, что ТЗ содержит исчерпывающий перечень требований к сайту, никаких иных требований к создаваемому продукту Заказчик предъявлять не может.
При этом если ТЗ хорошо проработано, то как правило под каждого клиента оно меняется незначительно (10%-30%). А в идеале, все условия для конкретного клиента выносить в отдельный документ — эскизный проект или оформлять протоколом разногласий.
Чтобы составить ТЗ заказчик должен обращаться к соответствующему специалисту — типа архитектурного бюро только для WEB-проектов. Вменяемый заказчик не будет нанимать студентов для написания ТЗ, а не вменяемые идут лесом, с ними лучше не работать вовсе.
У меня в студии проектная работа составляет не менее 30% от общего объема по ВСЕМ проектам (включая внутренние). Когда я выкидываю задание на оутсорсинг (не важно куда, на фриланс, частнику или другой компании) мы прорабатываем все до мелочей. Например если нужно спрограммить что-то, прописываю структуру классов, рисую схему взаимодействия между модулями, оговариваю где нужно транзакции использовать, где потенциально могут проявится ошибки и т.п. Если это задание художнику — то прорабатываем концепцию иллюстрации, что должно на ней быть изображено, в какой стилистике, в какой цветовой гамме (не говоря уже о формате итоговых файлов, вект/растр, цвет и т.п.)
Обращаясь за услугой нужно продумать все так, чтобы сторонний человек, даже не специалист но близкий к теме прочитал и все понял, что нужно делать. Кстати это очень хороший метод проверки — попросить своего знакомого прочитать и сказать что понятно, а что нет.
Проблема в том, что не все хорошие исполнители имеют достаточный уровень менеджмента чтобы проработать неподготовленную задачу, и понимают они ее так, как могут.
Еще, кроме самого ТЗ, всегда прописываю концепцию проекта и рисую эскизник. Т.к. без этого никуда.
Я работал с фрилансом и как заказчик и как исполнитель.
Согласен что найти адекватного исполнителя сложно (как и в реальной жизни), но еще сложнее поставить нормальное ТЗ. Если это сделать то работа работа идет как по маслу. Обоим сторонам это выгодно. До того как это понял — мучил и себя и исполнителя полтора месяца.
Для того чтобы сделать хорошее ТЗ, нужно обязательно въехать в тему того, что заказываешь. Мне пришлось самому разобраться в 3Dsmax-е и технологиях визуализации. Изучить основные нюансы, подготовить правильную с точки зрения композиции сцену. Решить вопрос со сведением текстур. Когда я все это сделал и передал четкие инструкции другой стороне — у нас с исполнителем не было ни одного конфликта. Результат можете посмотреть здесь
При работе в качестве подрядчика, я до начала работы самостоятельно перерабатываю ТЗ, утверждаю его с заказчиком и только потом приступаю к работе. Если заказчик отказывается это делать — то просто не работаю с ним.
Хорошая история, но однобокий взгляд на мир.
В жизни, как правило, ни водитель ни пассажир толком не знают куда едут. Пассажир готовит ТЗ их разряда маркером на глобусе нарисовать направление движения. Водитель, искренне хочет довезти пассажира до указанной точки, но как сами понимаете получить четкие координаты с такого ТЗ нереально.
Это проблема всей отрасли, а не только фриланса.
Удивительным для меня было то, что например показатель 15% успеха является нормальным для крупных интеграторов!
Причина в отсутствии такого понятия как проведение полноценной проектной работы. А ТЗ принято называть 4 листа с дурацкой схемой и набросками бизнес логики.
Идеальное сравнение со строительством — перед тем как строить дом, заказчик обращается в архитектурное агентство, заказывает разработку проекта (на бумаге). Потом рассчитывается смета. Только после этого строится дом.
Умному пассажиру нужно было искать не «бывалого» водителя, а сначала сходить в логистическую компанию, чтобы разработать четкий маршрут. А потом можно брать и не зажравшегося среднечка, и с песней вперед!
Уважаемый outcoldman, безусловно я в курсе что есть существенные различия в работе x32 и x64, у меня стоит 32-х битная версия ОС. Погуглить я пробую уже второй день, нашел только констатацию данной проблемы у некоторых пользователей но не решение.
Вообще круто, спасибо автору.
Потестил пример, есть одно замечание к юзабилити дерева: кликая мышкой по родительскому нет возможности выделить элемент чтобы ветка не сворачивалась :)
Хочу дополнить к пункту 6.Мониторить запросы, которые генерирует LINQ.
Это очень актуально для запросов с join-ами. Заметил, что если использовать более 1-го join-а и оператор into, в 80% случаев linq генерит неоптимальный код.
Еще есть удобный и бесплатный инструмет для работы с linq запросами — linqpad (скачать можно здесь www.linqpad.net)
Я уже имею опыт использования ASP.NET MVC в коммерческих проектах (начиная с Preview 3).
Лично для меня, помогло во многом упростить и ускорить процесс разработки. До MVC мы и так были вынуждены отказаться от ViewState, поэтому вся автоматизация WebForm полетела в жопу.
Что касается статьи (плюсы минусы технологий):
— ViewState это минус, минус в том, что отключив его перестают полностью работать Postback-и, приходиться все делать самому.
— Для WebForms, сложность верстки, т.к. отсутствует возможность повлиять на код, получаемый в результате.
А сравнение со строителями очень верное, более того, я считаю что в ИТ отрасли процент не успешных проектов можно значительно снизить используя технологии других отраслей, формирование которых происходило тысячелетиями (в т.ч. и строительства) и ничего зазорного здесь нет.
— тормозит (для меня это самый большой недостаток), могли бы сделать хотя бы работу с Task-ами на Ajax-е чтобы не ждать каждый раз перезагрузки 'тяжелой' страницы
— возможности по управления правами доступа к SVN для одного Space-а очень ограничены (всего 3 варианта Read, Read/Write, Own)
— Wiki глючит
— множество просчетов с юзабилити, например чтобы вбить затраченное время в Time Tracking нельзя ввести время с клавиатуры, нужно кликать мышкой чтобы выставить минуты (1 клик — ± 1 минута)
— Стоит дорого
Из плюсов могу ответить надежность данного сервиса
Последнее время все чаще задумываюсь о том что нужно искать что-то другое
У меня были другие болезни — был ярым C++-шником долгое время, считал все остальное недоязыками. Сейчас конечно более взвешенно отношусь, и использую то что лучше подходит для конкретной задачи.
>> Кто вам кстати сказал, что ТЗ пишется юридическим языком? «резиновая» и «статичная» верстка — это уже зависит от дизайн-макета.
ТЗ пишется техническим языком, но при этом все термины должны быть расшифрованы чтобы избежать двусмысленностей и неверного тракования если не дай бог потребуется судебное разбирательство, в т.ч. и резиновая верстка, блочная верстка
По пункту 1.
Упоминая 'соответствовать стандарту w3c' нужно расшифровывать что это за организация, привести ее полное название, адрес сайта. Кроме того, xHTML какой версии? Еще было бы неплохо привести ссылку на сам стандарт.
1. Данные налоговой инспекции
2. Данные человека
3. Данные о доходах
4. Подпись и печать
Как вы думаете, с какого раза человек правильно бы заполнил справку 2НДФЛ по такому шаблону? А подумайте какой удар по кредитным учреждениям нанес бы такой шаблон?
Что касается общих пунктов которые не хватает в вашем плане это:
— «ограничения» создаваемого сайта по нагрузке, максимальному кол-ву страниц, хостингу (требования к хостингу) и т.п.
— оговорки о том, что ТЗ содержит исчерпывающий перечень требований к сайту, никаких иных требований к создаваемому продукту Заказчик предъявлять не может.
При этом если ТЗ хорошо проработано, то как правило под каждого клиента оно меняется незначительно (10%-30%). А в идеале, все условия для конкретного клиента выносить в отдельный документ — эскизный проект или оформлять протоколом разногласий.
Обращаясь за услугой нужно продумать все так, чтобы сторонний человек, даже не специалист но близкий к теме прочитал и все понял, что нужно делать. Кстати это очень хороший метод проверки — попросить своего знакомого прочитать и сказать что понятно, а что нет.
Проблема в том, что не все хорошие исполнители имеют достаточный уровень менеджмента чтобы проработать неподготовленную задачу, и понимают они ее так, как могут.
Еще, кроме самого ТЗ, всегда прописываю концепцию проекта и рисую эскизник. Т.к. без этого никуда.
Согласен что найти адекватного исполнителя сложно (как и в реальной жизни), но еще сложнее поставить нормальное ТЗ. Если это сделать то работа работа идет как по маслу. Обоим сторонам это выгодно. До того как это понял — мучил и себя и исполнителя полтора месяца.
Для того чтобы сделать хорошее ТЗ, нужно обязательно въехать в тему того, что заказываешь. Мне пришлось самому разобраться в 3Dsmax-е и технологиях визуализации. Изучить основные нюансы, подготовить правильную с точки зрения композиции сцену. Решить вопрос со сведением текстур. Когда я все это сделал и передал четкие инструкции другой стороне — у нас с исполнителем не было ни одного конфликта. Результат можете посмотреть здесь
При работе в качестве подрядчика, я до начала работы самостоятельно перерабатываю ТЗ, утверждаю его с заказчиком и только потом приступаю к работе. Если заказчик отказывается это делать — то просто не работаю с ним.
В жизни, как правило, ни водитель ни пассажир толком не знают куда едут. Пассажир готовит ТЗ их разряда маркером на глобусе нарисовать направление движения. Водитель, искренне хочет довезти пассажира до указанной точки, но как сами понимаете получить четкие координаты с такого ТЗ нереально.
Это проблема всей отрасли, а не только фриланса.
Удивительным для меня было то, что например показатель 15% успеха является нормальным для крупных интеграторов!
Причина в отсутствии такого понятия как проведение полноценной проектной работы. А ТЗ принято называть 4 листа с дурацкой схемой и набросками бизнес логики.
Идеальное сравнение со строительством — перед тем как строить дом, заказчик обращается в архитектурное агентство, заказывает разработку проекта (на бумаге). Потом рассчитывается смета. Только после этого строится дом.
Умному пассажиру нужно было искать не «бывалого» водителя, а сначала сходить в логистическую компанию, чтобы разработать четкий маршрут. А потом можно брать и не зажравшегося среднечка, и с песней вперед!
Потестил пример, есть одно замечание к юзабилити дерева: кликая мышкой по родительскому нет возможности выделить элемент чтобы ветка не сворачивалась :)
Это очень актуально для запросов с join-ами. Заметил, что если использовать более 1-го join-а и оператор into, в 80% случаев linq генерит неоптимальный код.
Еще есть удобный и бесплатный инструмет для работы с linq запросами — linqpad (скачать можно здесь www.linqpad.net)
Лично для меня, помогло во многом упростить и ускорить процесс разработки. До MVC мы и так были вынуждены отказаться от ViewState, поэтому вся автоматизация WebForm полетела в жопу.
Что касается статьи (плюсы минусы технологий):
— ViewState это минус, минус в том, что отключив его перестают полностью работать Postback-и, приходиться все делать самому.
— Для WebForms, сложность верстки, т.к. отсутствует возможность повлиять на код, получаемый в результате.