В последнее время встречаю много руководителей в IT, которые проповедуют, что ТЗ, таск-трекеры, аналитики, архитекторы и документация в разработке никчемные "вещи" и не стоит на них тратить время и средства. И ладно если бы люди делали внешние проекты, там это как-то я еще могу обосновать, но когда дело касается внутренней автоматизации бизнеса, тут я не могу с ними никак согласиться и говорю, что Вы просто не умеете их "готовить".
Писал заметки для своей группы, понял, что получается больше, чем я рассчитывал, поэтому решил написать статью и выложить на Хабр целиком. Мне кажется, тут она сможет пригодится. Здесь нет технической информации, просто общее описание оптимального подхода к разработке сайта на заказ, так сказать результат моего опыта работы в веб-студии в течение трёх лет.
Читать полностью »
«Идеального технического задания не существует».
Не раз слышал фразы подобного рода, в ситуациях когда разработчики реализовали не «то» и не «там», при это ссылаясь на отсутствие идеального технического задания от заказчика, аргументируя: «если бы это было указано в ТЗ, тогда бы ..».
Читать полностью »
Мы продолжаем серию публикаций о разработке и производстве сложной современной электроники. В предыдущих статьях мы честно рассказали вам о нюансах, связанных с дизайном и изготовлением опытных образцов, с массовым производством, а теперь самое время перейти к вопросам, с которых начинается разработка конструкторской документации (КД) и от которых зависит успех взаимоотношений между заказчиком и разработчиком — создание концепции продукта и написание технического задания. Это первые шаги на пути к выпуску сложных серийных устройств и программного обеспечения (далее — продукта).
Читать полностью »
Бывают ситуации, когда проект нужно подготовить в очень сжатые сроки, и совсем нет времени на изучение способов решения задачи и выбора из них самого оптимального. Команда просто бросается с головой в реализацию, полагаясь на опыт и интуицию. Обычно получается хорошо. Но остается ощущение, что можно сделать лучше, была бы только возможность остановиться и обдумать задачу.
Например, в нашей команде разработки интернет-решений не у всех и далеко не всегда было понимание, с чего начинать проектирование: с прототипов интерфейсов или технического задания. В обоих случаях есть сторонники и противники, есть плюсы и минусы. Не хватает только единого мнения.
Читать полностью »
Думаю, многие слышали о законах роботехники, сформулированных Айзеком Азимовым:
Эти законы являются высокоуровневой моделью поведения каждого «правильного» (по версии Азимова) робота, но на этом их призвание не ограничивается.
В статье я чуть подробнее раскрою смысл этих законов, покажу, как они могут быть применены к сферам, отличным от робототехники, и попытаюсь выработать три закона разработки. Статья не несет прямой практической пользы, я это понимаю, поэтому заранее советую залезать под кат только тем, кому не жалко потрать несколько минут на мои рассуждения и обсудить их со мной в комментариях.
Читать полностью »
Разгребал «ящики» и обнаружил один очень интересный проект! Называется он SpecsMe, а направлен на решение одной из самых насущных проблем ИТ-агентств. Цель проекта: автоматизация составления ТЗ и создание инструментов для дальнейшей работы (удаленные доступы, одновременное редактирование, биржа и тд). Отдам в хорошие руки. Подробности под катом.
Несколько лет назад появился проект, который я посчитал достаточно интересным для себя, а именно — TzGen. Проект решал одну из основных задач веб-агентур того времени — составление технического задания. Идея показалась интересной — было решено написать его владельцам: интересовало развитие проекта, а также возможность инвестиций. Однако, ответа не получил. Через несколько месяцев, имея свободные ресурсы дизайнера и ПМ (себя лично), было принято решение своими руками создать новый проект. Что из этого получилось, смотрите ниже.
Здравствуйте, уважаемые коллеги!
Эта статья является очередной историей о работе с заказчиком, а так же нашим первым опытом при работе с большим проектом.
Цель урока: финальный урок по созданию приложения. Написание технического задания. Создание БД. Переименование webTemplate. Применение скаффолдинга. Админка. Основной сайт. Тесты.
Это финальный урок, и тут я немного отойду от конкретного программирования и поразмышляю о работе.
Программирование – это работа, это профессия, это творчество. Когда я учился в университете и с кем-то шел по дороге домой, мы часто спорили, что лучше Windows или Linux, Delphi или C++. Тогда мы могли не спать ночами, чтобы красиво переписать построение семантического дерева для компилятора. Мы изучали пролог, лисп, конечные автоматы, структуры данных. Мы учились видеть красоту быстрой сортировки Хоара реализованную на лиспе. ВО!:
(defun quicksort (lis) (if (null lis) nil
(let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
(append (quicksort (remove-if-not fn r)) (list x)
(quicksort (remove-if fn r))))))
Но теперь я рассматриваю программирование как услугу. Как что-то, за что мне платят деньги. Я занимаюсь фрилансом уже три года. В начале работы фрилансером я программировал не только веб и не только на asp.net mvc. Был и php на ZendFramework, и написание модулей для расчета стратегий для торговли на РТС на Quirk.