Комментарии 69
Расшифровка термина "Экстремальное программирование" очень порадовала:)"...а в субботу утром малость погулявшие накануне сотрудники несутся поднимать упавший сервер." Со стороны такая ситуация конечно выглядит, но от "пятничных" билдов некоторым компаниям почему-то бывает очень трудно отказаться и после полдюжины проваленных итераций...
да уж экстримальное программирование не имеет ничего общего с экстримом авралов
Все нормальные (опытные) разработчики составляют договор с заказчиком так, чтобы подобные требование вносить изменения стоили заказчику денег и вели к увеличению сроков. Тогда заказчик будет думать прежде чем что-то требовать. ИМХО, в задницу такого заказчика.
Согласен.
А если проект расчитан на год и стоит несколько сот К. И имеются единичные проблемы на промежуточном этапе.
Стоит ли портить отношения навязыванием увеличения бюджета на 1-2к?
Стоит ли посылать такого заказчика?
А если проект расчитан на год и стоит несколько сот К. И имеются единичные проблемы на промежуточном этапе.
Стоит ли портить отношения навязыванием увеличения бюджета на 1-2к?
Стоит ли посылать такого заказчика?
При правильном подходе все, что не вписывает в bug fix - переносится на следующий релиз. По крайней мере у нас так было. Финансирование в квартал около 5М евро было и заказчику особо не давали разгуляться. Менеджеры программеров держали на расслабоне. Если сделал все за 1 день, что нужно было делать 2-3 недели - то новой работой не загружали - можно было спокойно бить баклуши сидя в офисе, качая музло и т.п.
Авралы перед дедлайнов все же бывали, но заказчику это стоило далеко не 1-2к. Выходили на работу в субботу и воскресенье по 8 часов. Рядовым программерам чистыми начисляли по 160 евро в час. Представляю себе - сколько это стоило заказчику.
А людей на проекте было под 100.
Компания, где это все разрабатывалось имеет около 100к сотрудников по всему миру. Бюррократия при работе как с внешними заказчиками, так и с внутренними (когда один отдел для другого что-то клепает) стоит всегда на первом месте.
Что же, тогда могу только позавидовать грамотности менеджеров и дрессированности заказчика. У меня в свое время было убеждение, что там, где большие деньги - большая ответственность и дисциплина.
А когда столкнулся в жизни - оказалось большие разгильдяи =)
А когда столкнулся в жизни - оказалось большие разгильдяи =)
Если на работе сидят программисты и плюют в потолок - значит одно из двух:
Или много работы,но мало платят.
Или много платят,но мало работы.
Или много работы,но мало платят.
Или много платят,но мало работы.
У меня был случай именно на этом проекте. Нужно было сделать пару новых фич. Получалось, что по хорошему нужно делать сразу обе фичи, но по документам одну. Я сделал сразу обе, но чтобы включить вторую в конфигурации нужно заменить параметр с 0 на 1 нужно было. Через недели две ко мне пришел менеджер и спросил - сколько надо времени, чтобы сделать вторую фичу. Я ему хитро улыбнулся и позвал его к компу. Когда я ему показал, что чтобы сделать вторую фичу нужно заменить 0 на 1 в конфиге на AIX сервере, то он опух. Когда минут через 5 он сумел закрыть рот, то он мне сказал примерно следующее - "Ты главное не проговорись заказчику, что это так быстро делается. Нам нужно как минимум еще три недели, чтобы это сделать.". После этого я еще три недели прохлаждался.
да это вредительство и разбазаривание бюджета! представляю себе, как ваши менеджеры выкатывали заказчику график проекта.
зачастую после п.5 просто забивается на всё с помощью п.1 ;)
Спасибо! Если мог, поднял бы Вам карму :)
Я вот лично для себя вынес, что нужно четко формулировать задачи, дробить их на более мелкие и последовательно решать согласно приоритету. Но самое главное, нельзя забывать "позвонить заказчику".
Я вот лично для себя вынес, что нужно четко формулировать задачи, дробить их на более мелкие и последовательно решать согласно приоритету. Но самое главное, нельзя забывать "позвонить заказчику".
Спасибо автору за очень жизненный топик.
От себя добавлю несколько аспектов которые очень помогают мне по жизни:
0. Разрабатываем проекты:
- быстро
- качественно
- недорого
Выберите любых два пункта.
Шутки, шутками но заказчик должен понять что волшебники живут только в сказках. Чаще проще отказаться от проекта чем заработать себе плохую репутацию (отхабрят вас и кирдык).
1. Планирование, планирование, и еще раз планирование - на данный момент предпочитаю потратить половину времени проекта на планирование. Иногда даже доходит до абсурда когда хелп по продукту готов намного раньше самого продукта. Правильным, утвержденным у заказчика, планом вы избавляетесь от очень многих проблем (от креативности заказчика например)
2. Время разработки проекта = (предполагаемое время разработки) * 2.
3. Если работаете не над одним проектом то они имеют свойство начать аврализировать вас одновременно goto 1;
4. Пользуйтесь системами коллективной разработки. Много людей банально не могут организовать свое рабочее место (и себя за компанию)
5. Полностью согласен с 4 пунктом. Предлагаю так же усилить его. Информируйте заказчика на каждом этапе разработки. Покажите что Вы его уважаете. Вероятность ситуации "а вот это мне не нравится" за неделю до сдачи проекта уменьшается на 50%.
6. Заказчик должен вас уважать. Делайте все что угодно.
7. Не тряситесь над заказчиком. "А вот это вам нравится? Не нравится, сейчас переделаем...". У вас есть ПЛАН разработки утвержденный заказчиком. Это как на войне. Если планы хромают начинается героические штурмы. Если нет плана goto 1
8. Сделайте план.
9. Если возникает конфликт с заказчиком то это полностью ваша вина. Заказчику изначально конфилкты не нужны.
От себя добавлю несколько аспектов которые очень помогают мне по жизни:
0. Разрабатываем проекты:
- быстро
- качественно
- недорого
Выберите любых два пункта.
Шутки, шутками но заказчик должен понять что волшебники живут только в сказках. Чаще проще отказаться от проекта чем заработать себе плохую репутацию (отхабрят вас и кирдык).
1. Планирование, планирование, и еще раз планирование - на данный момент предпочитаю потратить половину времени проекта на планирование. Иногда даже доходит до абсурда когда хелп по продукту готов намного раньше самого продукта. Правильным, утвержденным у заказчика, планом вы избавляетесь от очень многих проблем (от креативности заказчика например)
2. Время разработки проекта = (предполагаемое время разработки) * 2.
3. Если работаете не над одним проектом то они имеют свойство начать аврализировать вас одновременно goto 1;
4. Пользуйтесь системами коллективной разработки. Много людей банально не могут организовать свое рабочее место (и себя за компанию)
5. Полностью согласен с 4 пунктом. Предлагаю так же усилить его. Информируйте заказчика на каждом этапе разработки. Покажите что Вы его уважаете. Вероятность ситуации "а вот это мне не нравится" за неделю до сдачи проекта уменьшается на 50%.
6. Заказчик должен вас уважать. Делайте все что угодно.
7. Не тряситесь над заказчиком. "А вот это вам нравится? Не нравится, сейчас переделаем...". У вас есть ПЛАН разработки утвержденный заказчиком. Это как на войне. Если планы хромают начинается героические штурмы. Если нет плана goto 1
8. Сделайте план.
9. Если возникает конфликт с заказчиком то это полностью ваша вина. Заказчику изначально конфилкты не нужны.
Замечу распространенную ошибку планирования, когда есть несколько проектов (с разными PM). Планы составляются с учетом чуть ли не 100% загрузки участников. Да, это детская ошибка, но уже надоело видеть ее вновь и вновь.
0. Известная тема :)
2. Перезаклад тоже плохо =( Снижается конкурентоспособность. Лучше делать так, чтобы в оценке участвовало два эксперта.
4. Нельзя ли подробнее о средствах коллективной разработки?
6. Согласен!! =)
9. Не всегда. Есть случаи, когда заказчик захочет "поиметь вас больше, чем он за это платит".
0. Известная тема :)
2. Перезаклад тоже плохо =( Снижается конкурентоспособность. Лучше делать так, чтобы в оценке участвовало два эксперта.
4. Нельзя ли подробнее о средствах коллективной разработки?
6. Согласен!! =)
9. Не всегда. Есть случаи, когда заказчик захочет "поиметь вас больше, чем он за это платит".
>> 4. Нельзя ли подробнее о средствах коллективной разработки?
Очень полезная связка TRAC + SVN. Как только будет карма опубликую статью из своего опыта по коллективной разработке благо наметки есть :)
Очень полезная связка TRAC + SVN. Как только будет карма опубликую статью из своего опыта по коллективной разработке благо наметки есть :)
Будем посмотреть :)
Карма поднялась на допустимый уровень - публикуем
http://habrahabr.ru/blog/pm/35918.html
спасибо всем кто поднял карму, надеюсь данная статья сможет чем-то помочь
http://habrahabr.ru/blog/pm/35918.html
спасибо всем кто поднял карму, надеюсь данная статья сможет чем-то помочь
Trac + SVN - очень хорошо для программных проектов.
Для тех, где много документации, по-моему, лучше всего SharePoint.
Для тех, где много документации, по-моему, лучше всего SharePoint.
Концепция SharePoint хороша, но киевское представительство Microsoft в свое время так и не смогло предоставить нормальное решение для работы с документами. Очень не удобно было (правда было год назад или 2 - не помню), может уже отладили. Тяжелое решение (почти весь софт Майкрософта ставить надо)
Не видел удачного использования для документооборота. Никто из знакомых так и не смог с ней работать (да и дорого это ;). Наверное нужны более серьезные програмные решения.
По поводу документации - очень хорошо подходит SVN.
Обосную. Для начала давайте определимся что имеется в виду под "документацией". Условно разделю ее на 4 вида:
0. Создание общей документации проекта
1. Создание документации API вашего проекта
2. Создание хелпа для вашего проекта
3. Создание туториалов для вашего проекта
Поподробнее:
0. Вам хочется описать проект со всех сторон. Данная документация является по сути вспомогательной - для разработчиков. Но может понадобится возможность печати для заказчика. Берем ВиКи - контроль версий в кармане. (ВиКи - модуль TRAC'а)
1. Создание документации API является по сути задачей важной. Но первопричиной есть хороший стиль написания комментариев в исходном коде. Потом просто используется соответсвующая утилита java - javadoc, php - PHPDoctor например, и т.д. для других языков. Соответсвенно наша задача - правильно писать исходный код - в SVN
2. На данный момент хелпы в основном пишутся из HTML (в свн) или для hh (что тоже HTML)
3. Туториал. Тут каких-то особых предпочтений среди разработчиков нет. Одни пишут отдельные приложения, другие делают скриншоты, третие скринкасты. Скринкасты лично я делаю на флеше, а флеш что? - правильно ложится в SVN
Так что вопрос с документацией в разработке я думаю решен (про скрепочки говорить я думаю не надо)
Подробнее надеюсь опишу в отдельном топике при наличие дастаточного количества маны, хабры, и кармы ;)
Не видел удачного использования для документооборота. Никто из знакомых так и не смог с ней работать (да и дорого это ;). Наверное нужны более серьезные програмные решения.
По поводу документации - очень хорошо подходит SVN.
Обосную. Для начала давайте определимся что имеется в виду под "документацией". Условно разделю ее на 4 вида:
0. Создание общей документации проекта
1. Создание документации API вашего проекта
2. Создание хелпа для вашего проекта
3. Создание туториалов для вашего проекта
Поподробнее:
0. Вам хочется описать проект со всех сторон. Данная документация является по сути вспомогательной - для разработчиков. Но может понадобится возможность печати для заказчика. Берем ВиКи - контроль версий в кармане. (ВиКи - модуль TRAC'а)
1. Создание документации API является по сути задачей важной. Но первопричиной есть хороший стиль написания комментариев в исходном коде. Потом просто используется соответсвующая утилита java - javadoc, php - PHPDoctor например, и т.д. для других языков. Соответсвенно наша задача - правильно писать исходный код - в SVN
2. На данный момент хелпы в основном пишутся из HTML (в свн) или для hh (что тоже HTML)
3. Туториал. Тут каких-то особых предпочтений среди разработчиков нет. Одни пишут отдельные приложения, другие делают скриншоты, третие скринкасты. Скринкасты лично я делаю на флеше, а флеш что? - правильно ложится в SVN
Так что вопрос с документацией в разработке я думаю решен (про скрепочки говорить я думаю не надо)
Подробнее надеюсь опишу в отдельном топике при наличие дастаточного количества маны, хабры, и кармы ;)
Извините, но ту часть вашего коммента, которая про SharePoint не понял. Он сам себе решение для работы с документами, что же еще должен был продемонстрировать киевский MS? И что он вообще показал?
На счет тяжелого решения - это, мягка говоря, преувеличение. Для небольшой команды (<50 человек) и небольшого объема документов (меньше 2-3 Гб) вполне достаточно Windows SharePoint Services, которые бесплатны, работают с SQL Express (тоже бесплатным). Какой дополнительный софт надо ставить?
А зачем вам вообще в проекте документооборот?
В пунктах 0-3 вы говорите исключительно о программных проектах. По сути о разработке. В этом наши позиции и расходятся.
0. В эту группу входит масса документации, от ТЭО до протоколов совещаний. Что делать, если мне надо вставить в текст картинку? Или какую-нибудь нетривиальную таблицу? Заморачиваться с вики-синтаксисом, загружать картинки?.. А потом объяснять заказчику, что текст криво криво отформатирован, потому что это копипейст из вики? (или, того хуже, печать напрямую)
1. Да, естественно, документация по исходникам должна генериться автоматически.
2. У нас инструкции пользователя в основном пишутся, печатаются, прошиваются и переплетаются. Пользователи привередливы ;)
Короче, кесарю - кесарево. На мой взгляд, для тяжелых документов в мс-офисных форматах пока ничего приличныее SharePoint все-таки не придумали. Если для ведения документации по проекту Вам достаточно, грубо говоря, блокнота (т.е. она в основе своей Plain Text'овая), то SVN - ваш выбор :)
На счет тяжелого решения - это, мягка говоря, преувеличение. Для небольшой команды (<50 человек) и небольшого объема документов (меньше 2-3 Гб) вполне достаточно Windows SharePoint Services, которые бесплатны, работают с SQL Express (тоже бесплатным). Какой дополнительный софт надо ставить?
А зачем вам вообще в проекте документооборот?
В пунктах 0-3 вы говорите исключительно о программных проектах. По сути о разработке. В этом наши позиции и расходятся.
0. В эту группу входит масса документации, от ТЭО до протоколов совещаний. Что делать, если мне надо вставить в текст картинку? Или какую-нибудь нетривиальную таблицу? Заморачиваться с вики-синтаксисом, загружать картинки?.. А потом объяснять заказчику, что текст криво криво отформатирован, потому что это копипейст из вики? (или, того хуже, печать напрямую)
1. Да, естественно, документация по исходникам должна генериться автоматически.
2. У нас инструкции пользователя в основном пишутся, печатаются, прошиваются и переплетаются. Пользователи привередливы ;)
Короче, кесарю - кесарево. На мой взгляд, для тяжелых документов в мс-офисных форматах пока ничего приличныее SharePoint все-таки не придумали. Если для ведения документации по проекту Вам достаточно, грубо говоря, блокнота (т.е. она в основе своей Plain Text'овая), то SVN - ваш выбор :)
Не говорю что это контроль версий+TRAC - панацея. Но очень полезная вещь. По поводу SharePoint - я не силен в этом програмном продукте. Были негативные опыты.
Спасибо за карму :)
Спасибо за карму :)
Если вы использовали шарепоинт 2 года назад, то это был 2003-й шарепоинт. сейчас есть бесплатный sharepoint services 3.0. там есть вики. если рассматривать с точки зрения документооборота, то там вы можете настроить воркфлоу, т.е. например маршруты прохождения документов от одного юзера к другому на согласование. ставится он очень просто качаете, запускаете, некст, некст, некст и готово. сначала, конечно, не понятно, как пользоваться, но потом освоитесь :) рекомендую попробовать
Кармой, кстати, помог. Пишите.
Глянул демо Trac. А там есть какое-то разделение на проекты или под каждый нужно по-новому ставить? А то показывает все тикеты скопом.
Под каждый нужно настраивать свою "рабочую среду".
В принципе делается одной командой и копипастом строк в конфиге апача.
Если Вы про инсталляцию (файлы самого trac), то она в единственном числе.
В принципе делается одной командой и копипастом строк в конфиге апача.
Если Вы про инсталляцию (файлы самого trac), то она в единственном числе.
Если надо по проектам и без интеграции с SVN - то посмотрите из бесплатных
http://www.streber-pm.org/
http://www.streber-pm.org/
Концепция трака такова: один проект - один инстанс трака. К сожалению не всегда удобно :(. Особенно неудобно отслеживать в таком случае общую загрузку девелопера, когда у него есть таски из разных проектов (например один основной ну и парочка на саппорте). В таком случае приходится метаться по куче траков.
Помнится что раньше народ делал какие то дополнительные модули для поддержки нескольких проектов в рамках одного трака, но я перестал следить за ними, так что их актуальное состояние не знаю.
Но если вам не нужна одновременная поддержка нескольких проектов в рамке одного трака - то трак очень и очень удобная и приятная вещь :)
Помнится что раньше народ делал какие то дополнительные модули для поддержки нескольких проектов в рамках одного трака, но я перестал следить за ними, так что их актуальное состояние не знаю.
Но если вам не нужна одновременная поддержка нескольких проектов в рамке одного трака - то трак очень и очень удобная и приятная вещь :)
2. Формула была вроде такая: Время разработки проекта = (Предполагаемое время разработки)*Pi
Как мне это все близко. После выживания в около 8 таких задниц уже как то по-филосовски отношусь и не нервничаю.
Работать на делайн это как работать "до ночи" -
результат такой работы - говно по определению.
имхо.
про дизайн знаю точно, как обстоят дела с версткой и программированием догадываюсь.
результат такой работы - говно по определению.
имхо.
про дизайн знаю точно, как обстоят дела с версткой и программированием догадываюсь.
Да... Это мне очень знакомо. Особенно важно, как я считаю, это успокоиться. Неопытные разработчики очень часто впадают в панику. А этого как раз делать не нужно. Рассудительный и трезвый взгляд на вещи - наш рулевой!
Помимо планирования как такогого, еще очень важно построить, так называемое, дерево целей и задач. В этом случае заказчик всегда знает, зачем конкретно предпринимается каждое действие с Вашей стороны, а также становится проще отмахаться от "хотелок" заказчика (типа она не вписывается ни в одну цель). Плюс это повышает Ваш вес в глазах заказчика.
Думаю важнее всего трезвый взгляд на свои возможности, ну и самоорганизация. Из своего опыта: если чуствуешь что заказчик утягивает тебя в аврал - берешь тайм-аут и без паники все обдумываешь, все дополнительные требования документируются, это занимает мало времени и сильно уменьшает вероятность "геммороя".
Лично я бы уже наверняка все закончил, если бы заказчики знали, чего хотят...
Крайне советую почитать книгу "Экстремальное программирование: постановка процесса. С первых шагов и до победного конца" (автор Ауэр, Миллер).
чтоб заказчик не требовал в последний день все переделать или "добавить еще вот эту полезную фукнцию", надо четко договариваться, что вы обязаны делать (обычно это обгаваривается в ТЗ).
Все остальные пожелания - за отдельные деньги и в новые сроки
Все остальные пожелания - за отдельные деньги и в новые сроки
у меня самая тяжелая ситуация была, когда за пару часов надо было разобраться в чужом плохо написанном коде.после этого мне все было нипочем:)
Мегареспект автору!
"... будьте честны с менеджерами, заказчиками и самим собой. Не стоит при получении длинного списка требований и нереальных сроков брать под козырек и говорить ‘будет сделано’ ..." - просто золотые слова
"... будьте честны с менеджерами, заказчиками и самим собой. Не стоит при получении длинного списка требований и нереальных сроков брать под козырек и говорить ‘будет сделано’ ..." - просто золотые слова
Авралы и подобные причины авралов маловероятны, когда команда работает не на заказчика, а на себя.
Согласен.
Но иногда и рынок торопит. А с ним пытаться договориться, к сожалению, бесполезно.
Но иногда и рынок торопит. А с ним пытаться договориться, к сожалению, бесполезно.
К сожалению, при грамотной постановке задачи количество "авралов" не зависит от того на кого работает команда.
Ведь по сути что такое "аврал" - это отклонение от сроков.
Я думаю Вы не будете спорить что как при работе на себя так и на дядю - сроки всегда должны быть.
Хотя и не могу не согласиться, что нужно обладать БОЛЬШОЙ сознательностью чтобы не сказать "а ну его на%... пойду погоняю в думик" при возникновении авралов
Ведь по сути что такое "аврал" - это отклонение от сроков.
Я думаю Вы не будете спорить что как при работе на себя так и на дядю - сроки всегда должны быть.
Хотя и не могу не согласиться, что нужно обладать БОЛЬШОЙ сознательностью чтобы не сказать "а ну его на%... пойду погоняю в думик" при возникновении авралов
Интересно, спасибо.
"тратиться"
без "ь"
"тратиться"
без "ь"
По данной теме рекомендую прочитать книгу "Искусство управления IT-проектами", автор Скотт Беркун.
Стив Макконнелл советует в таких ситуациях напомнить заказчику, что вносимые изменения не оговорены в ТЗ и "нам придется пересмотреть смету и сроки работ". После этих волшебных слов половина требований тут же превращается в пожелания.
Спасибо.
Внимательный читатель, я думаю, заметит - а не о базовых ли понятиях управления проектами идет речь. Именно о них. Есть задача, дифицит ресурсов и сроки к которым необходимо получить некоторый результат. Разница, пожалуй, только в стрессе, который сопутствует авралам.
Дефицит..
Внимательный читатель, я думаю, заметит - а не о базовых ли понятиях управления проектами идет речь. Именно о них. Есть задача, дифицит ресурсов и сроки к которым необходимо получить некоторый результат. Разница, пожалуй, только в стрессе, который сопутствует авралам.
Дефицит..
обычно сроки надо прикинуть при получении задания, а поом удвоить или даже утроить. В программировании и вебпроектах столько подводных камней при тестировании появляется, что их обход половина работы.
А мне нравится работать в авральном режиме. Когда нет права на ошибку. Концентрация и эфективность работы возрастает многократно. Потом недельку побездельничать и опять любимый аврал.
Да, вот как раз сейчас работаю в аврале — это ужас! Действую в таких случаях как Вы и советуете) Ух предстоит весёлая ночь)
Вообще говоря, это одна из проблем российского IT менеджмента. Программеров (в широком смысле) загоняют настолько сильно, что после 35 работать способны единицы. В принципе, решаемо. :)
интересно почитать, у меня возникла было проблема что заказчик, после того как я сделал работу всю по ТЗ, говорил "а вот этого почему нет, я думаю, что это должно быть в стандарте..". Ладно доделал что он ещё написал. Сдаю ему, а он опять что нибудь..
И получается что это было не обговорено, а чтобы сейчас это реализовать нужно переделать часть работы уже сделанной в начале.
И получается что это было не обговорено, а чтобы сейчас это реализовать нужно переделать часть работы уже сделанной в начале.
в случае, когда есть 15 задач необходимых к дедлайну, впервую очередь необходимо выполнить самые несущественные, простые и понятные задачи. Для кого-то это может быть естесственным, но я достаточно раз сталкивался с тем, что человек тратит 40% времени на сложную задачу так и не решив ее на должном уровне, а ко всему этому еще и не сделано то, что можно было сделать с легкостью.
а у меня другой загон.. клиент постоянно хочет что то переделать.. но радует то что он всегда за это платит.)
Не поможет. У меня "продолжительный аврал" с середины декабря: каждый раз думаю, что на этой неделе закончится, а оно все со следующей только набирает обороты.
единственно, с чем соглашусь - не нужно брать на себя больше работы, чем реально можешь переработать. Однако, бывают ситуации, когда с этим ничего не сделать. Например, у меня 3 официальных работы и все-бы хорошо, пока:
- Всем начальникам и постоянным заказчикам сразу вдруг что-то понадобилось, и причем, срочно
- Один из заказчиков, проплативших деньги вперед, проснулся с материалом, а срок сдачи "завтра"
В работе с постоянными клиентами иногда бывают ситуации, кода не отказать, иначе клиент "обидится и уйдет". Хотя, иногда хочеться всех послать и забить на все...
единственно, с чем соглашусь - не нужно брать на себя больше работы, чем реально можешь переработать. Однако, бывают ситуации, когда с этим ничего не сделать. Например, у меня 3 официальных работы и все-бы хорошо, пока:
- Всем начальникам и постоянным заказчикам сразу вдруг что-то понадобилось, и причем, срочно
- Один из заказчиков, проплативших деньги вперед, проснулся с материалом, а срок сдачи "завтра"
В работе с постоянными клиентами иногда бывают ситуации, кода не отказать, иначе клиент "обидится и уйдет". Хотя, иногда хочеться всех послать и забить на все...
Это все конечно хорошо.. но!
Или сталкиваюсь с такими проектами или самому не хватает скилзов (что врят ли), но как правило элементарно на все эти вещи (я бы сказал с п.№5) уже просто не хватает времени. Но за советы спаибо - комментарии порадовали!
Или сталкиваюсь с такими проектами или самому не хватает скилзов (что врят ли), но как правило элементарно на все эти вещи (я бы сказал с п.№5) уже просто не хватает времени. Но за советы спаибо - комментарии порадовали!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пристрелите меня, или опять дедлайн.