Одна авария не может грохнуть код всего проекта на всех компьютерах, где он имелся - от рабочих компьютеров разработчиков до серверов. Подозреваю, что если и есть в этой публикации зерно истины, то вот оно:
не только о технических, но и о кадровых проблемах исполнителя
Обидевшийся программист уничтожает код всего проекта везде. Вполне реально.
Я знаю. Я имею в виду вот что. Если мое мнение в среднем воспринимается нейтрально или положительно, то откуда прилетели два минуса? С учетом моего мизерного участия в хабре это было неожиданно:)
Всяко бывает. Вот например я - в блог не писал, только комментировал, и то, всего тридцать каментов, собиравших либо плюсы либо ноль. И тем не менее, у меня отрицательная карма по двум голосам. Почему так? Не знаю. :) Обидно.
(Пока писал этот коммент, кто-то добрый проголосовал еще и поднял карму до -1 - спасибо).
Нет, это не набор фотографий. На самом деле это длиннючее панно с вертикальными микропризмами, расположенными так, что под одним углом к панно видно только одну картинку; чуть меняешь угол - уже другую. Примерно как старые советские календарики, помните, такие были?
Эта технология очень дешевая. Кажется, на хабре полгода назад проскакивала ссылка на компанию, которая их делает, там и принцип рассказывается. Ссылку искать лень.:)
Знаете, я вот почитал всю эту мегакритику и расстроился. Система ваша делает ровно то, что она делает. Осмысить ее очень просто. За пять минут вменяемый человек сможет начать ею пользоваться. Юзабилити у нее после пяти минут использования я лично оцениваю очень позитивно. Мне все равно кто делал дизайн, но этот дизайн вызывает желание систему открывать и работать в ней снова и снова. В других же системах порой наоборот - система воспринимается исключительно как неизбежное зло. :( А психологический комфорт работы с такой повседневной штукой рулит очень и очень.
Так что я рад, мне эта штука понравилась и я буду следить за ее развитием.
1. Мне кажется, данная проблема лежит несколько глубже. Надо понять, по какой причине заказчик игнорирует предварительные материалы.. например, ему наплевать на проект, и для него он - отмазка, обязаловка или еще что-то. В этом случае МАСТ свалить как можно раньше и бесконфликтнее - успеха в таких проектах не бывает. Может быть, ему страшно вникать, он боится погружаться в очередную область знаний, где он не вполне уверенно себя чувствует. В этом случае надо дать заказчику ответ на его страхи и показать, что это - несложно. Может быть, он не знает, что именно вы от него ожидаете, с какой стороны ему подойти к материалам. В таком случае нужно вместе с ним пройти пару "уроков" и показать образец ожидаемого фидбека. Может быть, заказчик считает, что раз он уже объяснил вам, чего он хочет, то вы телепатически должны сами все сделать "правильно". В любом случае, без фидбека вы просто ставите работу на паузу и миролюбиво ждете. Давить на заказчика - опасно и неправильно, он будет испытывать не только психологический дискомфорт, но и точно будет знать, от кого он исходит. И в итоге может дать вынужденный фидбек, и это будет для вас еще хуже - вроде и фидбек есть и заново не потребуешь, а вроде и понятно, что фидбек ведет в пропасть. В любом случае, без личной заинтересованности заказчика в обсуждении задачи и проекта - проект никак не может состояться успешно, потому что понятие успеха в данном случае детерминируется заказчиком, а наш заказчик не может дать ответ на простые вопросы.
2. "Нет времени писать ТЗ" и "ТЗ должно быть всеобъемным и максимально точным" - на этих, казалось бы, диаметрально противоположных позициях могут стоять только дети, совсем недавно начавшие фрилансерскую карьеру или софтверный бизнес. Тут нечего говорить - работа и все соглашения должны быть продокументированы, просто не надо писать фолианты скучных тупых ТЗ, которые дружно все игнорируют. Надо понять не только суть, но и дух agile методологий - и вот тогда это работает. Еще неплохо бы несколько раз наступить на болезненные грабли, связанные с работой "на честном слове" - ну, а как иначе закреплять знания?:)
3. Работа сверх ТЗ должна оплачиваться. Это должно пониматься как нечто настолько само собой разумеещееся, что ни одной из сторон не придет в голову это обсуждать. Подчеркиваю - ни одной. Повторяю - обсуждать. По аналогии с рестораном - вы, конечно, можете поставить на стол бесплатные закуски, но это потому что вы угощаете, а не потому "тут так принято". И в ресторане вы ниче не обсуждаете, вы пришли, покушали, заплатили. Вы отработали столько-то часов - выставили счет - счет оплатили. Многие думают, что это возможно только с идеальным заказчиком в вакууме, но это не так. Это зависит только от того, как вы себя спозицинируете в отношениях и на какой уровень вы претендуете. (Естественно, это при условии вашего профессионального подхода. Контора, делающая сайты-за-$200, заслуживает к себе соответствующего отношения)
4. Заказчика обязательно надо держать в курсе методологии. В частности, МАСТ предупредить его о том, что никогда не бывает так, чтобы писалось ТЗ, создавался продукт и продукт сразу удовлетворял пожелания заказчика. Он должен понимать, что доводка будет обязательно, причем может по бюджету спокойно выйти даже на 100% сверх и эти затраты НЕ прогнозируются. Если заказчик с этим не согласен - вы НЕ РАБОТАЕТЕ, потому что иначе вы поставите шах и мат не только себе но и проекту. Ведь все равно недоведенный софт закзачик не примет (все проиграли), или доводку придется делать вам за свой счет (вы проиграли, заказчик выйграл).
5. Частая интеграция и показывание заказчику софта по мере готовности - палка о двух концах. С одной стороны, очень полезно, чтобы он шарил с вами ответственность за результат. С другой стороны, см.п.1. - фидбек может быть нерелевантен. С третей стороны, дураку полработы не показывают, а заказчик в области софта всегда дурак, потому что у него другая сфера компетенции.
не только о технических, но и о кадровых проблемах исполнителя
Обидевшийся программист уничтожает код всего проекта везде. Вполне реально.
(Пока писал этот коммент, кто-то добрый проголосовал еще и поднял карму до -1 - спасибо).
Эта технология очень дешевая. Кажется, на хабре полгода назад проскакивала ссылка на компанию, которая их делает, там и принцип рассказывается. Ссылку искать лень.:)
Так что я рад, мне эта штука понравилась и я буду следить за ее развитием.
2. "Нет времени писать ТЗ" и "ТЗ должно быть всеобъемным и максимально точным" - на этих, казалось бы, диаметрально противоположных позициях могут стоять только дети, совсем недавно начавшие фрилансерскую карьеру или софтверный бизнес. Тут нечего говорить - работа и все соглашения должны быть продокументированы, просто не надо писать фолианты скучных тупых ТЗ, которые дружно все игнорируют. Надо понять не только суть, но и дух agile методологий - и вот тогда это работает. Еще неплохо бы несколько раз наступить на болезненные грабли, связанные с работой "на честном слове" - ну, а как иначе закреплять знания?:)
3. Работа сверх ТЗ должна оплачиваться. Это должно пониматься как нечто настолько само собой разумеещееся, что ни одной из сторон не придет в голову это обсуждать. Подчеркиваю - ни одной. Повторяю - обсуждать. По аналогии с рестораном - вы, конечно, можете поставить на стол бесплатные закуски, но это потому что вы угощаете, а не потому "тут так принято". И в ресторане вы ниче не обсуждаете, вы пришли, покушали, заплатили. Вы отработали столько-то часов - выставили счет - счет оплатили. Многие думают, что это возможно только с идеальным заказчиком в вакууме, но это не так. Это зависит только от того, как вы себя спозицинируете в отношениях и на какой уровень вы претендуете. (Естественно, это при условии вашего профессионального подхода. Контора, делающая сайты-за-$200, заслуживает к себе соответствующего отношения)
4. Заказчика обязательно надо держать в курсе методологии. В частности, МАСТ предупредить его о том, что никогда не бывает так, чтобы писалось ТЗ, создавался продукт и продукт сразу удовлетворял пожелания заказчика. Он должен понимать, что доводка будет обязательно, причем может по бюджету спокойно выйти даже на 100% сверх и эти затраты НЕ прогнозируются. Если заказчик с этим не согласен - вы НЕ РАБОТАЕТЕ, потому что иначе вы поставите шах и мат не только себе но и проекту. Ведь все равно недоведенный софт закзачик не примет (все проиграли), или доводку придется делать вам за свой счет (вы проиграли, заказчик выйграл).
5. Частая интеграция и показывание заказчику софта по мере готовности - палка о двух концах. С одной стороны, очень полезно, чтобы он шарил с вами ответственность за результат. С другой стороны, см.п.1. - фидбек может быть нерелевантен. С третей стороны, дураку полработы не показывают, а заказчик в области софта всегда дурак, потому что у него другая сфера компетенции.
Мда:) Кажется, вы - ЦА того самого статейного юмора. :)