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