営業、受注、制作、納品、運用と、ウェブ制作の活動は長期に渡り、そのタスクの種類と量は膨大です。だからこそ、基本的なプロセスや使用するドキュメントなどを明確に定義しておかないと、サービスの品質が担当者により大きく変わることになります。 ベイジは社員がまだ5名の頃、各人に委ねた進め方によって以下のようなトラブルが頻発していました。 ミスが発生しても「次から気をつける」と精神論で終わらせてしまう 担当するディレクターやクリエイターによってタスクの抜け漏れが起きる 担当者それぞれが属人的な進め方をしてて品質が安定しない 役割が不明瞭なグレーゾーンのタスクが放置されてしまう 創造的な仕事の時間が、ルーチンや計画にないタスクに奪われてしまう 新しい社員が入る度に同じことを教えないといけない これら問題を解決するため、2014年頃からワークフローを整備するようになりました。ちなみに私が入社したのはこれ以
たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算
はじめに この記事は、ライブドアが7月15日にリリースした新サービス「ロケタッチ」の開発メンバーが、リレー形式でお送りする連載企画です。 サービスの企画・開発に携わる方々の今後のヒントとなれるよう、プロデューサー / ディレクター / デザイナー / プログラマー / マークアップエンジニアなどそれぞれの視点から、ロケタッチ開発時の課題と、それを乗り越えるために行った工夫をご紹介していきます。 こんにちは、佐々木です これまで「プロデューサー」を名乗ったことはなかったのですが、ロケタッチで果たした役割ごとのノウハウを連載にするということで、「プロデューサー編」の担当をすることになりました。よろしくお願いします。 ちなみにここで私がいうプロデューサーの役割というのは、 (1)「コンセプト設計」 (2)「いちユーザーとしての試運転」 のふたつです。 これは言うなれば、誰よりも遠くから眺めつつ、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
