просто нужно говорить с людьми на их языке.
если ты финансистам говоришь — будьте добры, давайте все перепишем, потому что не хватает IoC и без ORM проект крив архитектурно — пошлют.
а изложив что-то вроде:
— ЗП программера * 1 месяц рефакторинга * 2 программера + ЗП архитектора <<< ЗП на переписывание всего с нуля после задач N, P, Q, которые вы хотите видеть сделанными в будущем.
то есть что отрефакторив, они экономят бабло, причем убедительно и авторитетно — вполне можно договориться. ИМХО.
переписываем, каждую пятницу рефакторинг. а после первого этапа иногда целую неделю я даю переписать. фигли, я же менеджер, вышедший из программистов, понимаю зачем это нужно.
в плане расходов — есть законы чисто программерские, а есть экономические расчеты.
например, можно сделать загрузку на месяц раньше и заработать на ней два миллиона рублей. а можно делать ее три месяца и просрать момент на рынке.
и да, должен заметить, я долго думал, как сформулировать свои мысли,
но после того, как наткнулся на Вашу отличную статью, просто был в шоке, насколько точно все можно описать :)
тем не менее, решил еще раз обдумать и написать что-то свое. как там кто-то советовал, пишите и тренируйтесь :)
я убежден, что умение работать на результат — то, чему можно научить, но самому научиться сложно.
подавать пример — очень заразная привычка. разумеется, без этого нельзя, но кто сказал, что сотрудники не будут думать — ну вот пусть и работает за всех :) ясное дело, это решается контролем, но весь вопрос в деталях.
если человек знает, что с него не просто спросят отчет, а попросят показать результат, вполне себе четкий, а не пару строк в workflow системе — он мыслит иначе.
ясно, это стрессовый режим. так как не всегда бывает вдохновение, и так далее.
но вот давайте будем честными. тут все знают про GTD, про правило бить задачи крупные на мелкие. почему в работе не помогать людям развивать в себе эти навыки? и людям саморазвитие, и делу польза.
смысл не в том, чтобы относиться к работникам, как к рабам.
смысл в том, чтобы людям показать — здесь и сейчас нужен результат, а не просиживание штанов.
за редким исключением, во многих областях можно показывать результат в конце дня.
а если просто человек ЧУТь-ЧУТЬ не дорисовал, не исправил небольшой баг — он часто и завтрашний день повторяет то же самое, но с другой задачей.
блин, ко мне приходит человек, говорит — хочу 50,000 рублей (без опыта работы причем), место, макбук, хуюк, кофе, обеды и мальчика, чтобы обмахивал от солнца и мух разгонял.
я не готов с ним работать.
а если приходит молодой, способный, глаза горят — окей. сначала с меньшей ЗП начинаем, но человек каждый день доводит задачи до конца, до результата. идут месяц, второй, год -и человек сам видит, что он растет. благодаря практике результативности, практике малых побед.
итак, я не говорю, что это должно быть всегда. но навыки работать не просто планомерно в течение хотя бы недели, а выдать результат именно сейчас, не после 19:00 забить хрен и уйти, а добить, задержавшись до 9, а затем спокойно завтра прийти позже (Или уйти раньше)
по поводу проектов — можно выделить стадию самодостаточности.
грубо говоря, вот если вы запустите проект и оставите его на год, а он проработает — значит, это конечный результат. да, он может быть криво написанным, неудобным, еще что-то, но будет решать главные задачи.
если же проект не взлетает, не работает, не решает своих задач — самодостаточность еще не достигнута.
затем стадия логической связности. весь функционал логичен, все элементы интерфейса логичны.
потом — визуальный тюнинг. уже можно вешать рюшечки, заниматься аудитом юзабилити, и так далее.
Доведение до конца = доведение до конечного результата.
Это ясно, что хорошие проекты поддерживаются нередко в течение многих лет.
Весь вопрос в том, чтобы четко выделить первый этап — собственно, рождение проекта и его оживление, и затем допилку. Если эти стадии не разделить — будет долгострой, который часто клиенту не нужен, потому что время ушло. И плюс на каждой стадии своя специфика работы — я бы даже сказал, очень разная
Для начала скажем, что слово «до конца» — часто субъективное ощущение. Клиент понимает по-своему, вы по-своему. Хорошо бы это понимание синхронизировать, сначала на уровне мышления, затем на уровне договора.
И, выделив некую стадию, после которой проект объективно можно запускать, считать достижение этой стадии — доведением до конца. Грубо говоря, сделали магазин и через него уже можно продавать — вот это доведение до конца. Но да, клиент хочет уже сразу и лучшие товары дня на главную, и спецакции вывести — но нужно, чтобы клиент понимал — это уже доработки, допилка самодостаточного проекта, а не минимальное необходимые работы по проекту, чтобы проект тупо взлетел.
Даже в сложных проектах, таких, как софт, можно набросать прототип, эскизный вариант за короткое время. Пусть это даже неделя — вместо месяца. Пусть там говнокод, который потом все равно будет переписан.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — еще хороший способ снизить издержки на переработку под изменения в дальшейшем. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
Даже в сложных проектах, таких, как софт, можно набросать прототип, эскизный вариант за короткое время. Пусть это даже неделя — вместо месяца. Пусть там говнокод, который потом все равно будет переписан.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — тупо хороший способ снизить издержки на коренную переработку. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
Будущее уже наступило — информация будет свободной, это следующий шаг в развитии.
А вот как это монетизировать — люди пока не придумали. И живут быдлопонятиями прошлого — копирастией и прочими заболеваниями.
Все нужно оценивать в динамике. и обновлять свои оценки других людей, ситуаций, вещей — всего — в своей голове.
потому что мы делаем срез, и время идет — меняется все, кроме, мля, оценки в голове.
просто нужно говорить с людьми на их языке.
если ты финансистам говоришь — будьте добры, давайте все перепишем, потому что не хватает IoC и без ORM проект крив архитектурно — пошлют.
а изложив что-то вроде:
— ЗП программера * 1 месяц рефакторинга * 2 программера + ЗП архитектора <<< ЗП на переписывание всего с нуля после задач N, P, Q, которые вы хотите видеть сделанными в будущем.
то есть что отрефакторив, они экономят бабло, причем убедительно и авторитетно — вполне можно договориться. ИМХО.
в плане расходов — есть законы чисто программерские, а есть экономические расчеты.
например, можно сделать загрузку на месяц раньше и заработать на ней два миллиона рублей. а можно делать ее три месяца и просрать момент на рынке.
но после того, как наткнулся на Вашу отличную статью, просто был в шоке, насколько точно все можно описать :)
тем не менее, решил еще раз обдумать и написать что-то свое. как там кто-то советовал, пишите и тренируйтесь :)
система сложная, вовсе не за естимейт.
ноу-хау.
и всегда имею рамку — «вот этого на сегодня будет достаточно». чтобы спать спокойно :)
подавать пример — очень заразная привычка. разумеется, без этого нельзя, но кто сказал, что сотрудники не будут думать — ну вот пусть и работает за всех :) ясное дело, это решается контролем, но весь вопрос в деталях.
если человек знает, что с него не просто спросят отчет, а попросят показать результат, вполне себе четкий, а не пару строк в workflow системе — он мыслит иначе.
ясно, это стрессовый режим. так как не всегда бывает вдохновение, и так далее.
но вот давайте будем честными. тут все знают про GTD, про правило бить задачи крупные на мелкие. почему в работе не помогать людям развивать в себе эти навыки? и людям саморазвитие, и делу польза.
смысл в том, чтобы людям показать — здесь и сейчас нужен результат, а не просиживание штанов.
за редким исключением, во многих областях можно показывать результат в конце дня.
а если просто человек ЧУТь-ЧУТЬ не дорисовал, не исправил небольшой баг — он часто и завтрашний день повторяет то же самое, но с другой задачей.
блин, ко мне приходит человек, говорит — хочу 50,000 рублей (без опыта работы причем), место, макбук, хуюк, кофе, обеды и мальчика, чтобы обмахивал от солнца и мух разгонял.
я не готов с ним работать.
а если приходит молодой, способный, глаза горят — окей. сначала с меньшей ЗП начинаем, но человек каждый день доводит задачи до конца, до результата. идут месяц, второй, год -и человек сам видит, что он растет. благодаря практике результативности, практике малых побед.
итак, я не говорю, что это должно быть всегда. но навыки работать не просто планомерно в течение хотя бы недели, а выдать результат именно сейчас, не после 19:00 забить хрен и уйти, а добить, задержавшись до 9, а затем спокойно завтра прийти позже (Или уйти раньше)
грубо говоря, вот если вы запустите проект и оставите его на год, а он проработает — значит, это конечный результат. да, он может быть криво написанным, неудобным, еще что-то, но будет решать главные задачи.
если же проект не взлетает, не работает, не решает своих задач — самодостаточность еще не достигнута.
затем стадия логической связности. весь функционал логичен, все элементы интерфейса логичны.
потом — визуальный тюнинг. уже можно вешать рюшечки, заниматься аудитом юзабилити, и так далее.
Это ясно, что хорошие проекты поддерживаются нередко в течение многих лет.
Весь вопрос в том, чтобы четко выделить первый этап — собственно, рождение проекта и его оживление, и затем допилку. Если эти стадии не разделить — будет долгострой, который часто клиенту не нужен, потому что время ушло. И плюс на каждой стадии своя специфика работы — я бы даже сказал, очень разная
И, выделив некую стадию, после которой проект объективно можно запускать, считать достижение этой стадии — доведением до конца. Грубо говоря, сделали магазин и через него уже можно продавать — вот это доведение до конца. Но да, клиент хочет уже сразу и лучшие товары дня на главную, и спецакции вывести — но нужно, чтобы клиент понимал — это уже доработки, допилка самодостаточного проекта, а не минимальное необходимые работы по проекту, чтобы проект тупо взлетел.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — еще хороший способ снизить издержки на переработку под изменения в дальшейшем. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — тупо хороший способ снизить издержки на коренную переработку. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.