開発者が考える提案書テンプレート markdown版 - Qiita
概要 定型的な システム開発 では以下のような設計書が使われる。 システム要件定義 システム方式定義 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 しかしそれ以前に 開発者目線、開発者発信で顧客に提案する概要資料を作りたい ケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。 オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。 技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し
得られた知見をフリーズドライ〜情報共有のための仕組み Report.md の紹介〜 - クックパッド開発者ブログ
こんにちは、会員事業部の新井（@SpicyCoffee66）です。今年はレシピサービスにおける体験改善を主な業務としていました。 サービス開発かラブライブ！の話をすると早口になります*1。今日はついにスマブラが発売されるのでおそらく早退します。 さて、本記事ではサービス開発において重要な要素である施策結果・知見のプールや共有について、社内でどのような取り組みが行われているのかを紹介したいと思います。 施策の結果から最大限に学びを得たい 私たちはサービス開発を進める中で日々多くの施策を実施することになります。 サービス開発のプロセスにおいて、施策は実施して終わりではなく、その結果からいかに多くの学びを得るのかということが重要になります。 施策の結果から学びを得るためには、その施策の意図や結果を可能な限り 正しく 解釈し、それを（将来入ってくるメンバーを含めて）より多くの人に 共有 することが
仕様書の書き方 - Qiita
仕様書を書く上で必要かなと思うことをまとめてみた。 対象者は、まだ仕様書なんて書いたことないよとか、何書くかいつも悩む、という方。 ここでいう仕様書とは、開発前の設計書というよりは、運用フェーズに引き渡す前に用意しておいたほうがよいドキュメント、という位置づけ。 仕様書の目的 仕様書を書く目的は、新しい人がチームに来た時に、スムーズに業務に取り組めること。 また、「人は時間が経つと必ず忘れる」ので、将来の自分のためでもある。 大事なこと 仕様書の目的を明確にする。 あれもこれも、と情報をたくさんのせても混乱する。 「仕様書にもメンテナンスコストがかかる」ことに注意する。 仕様書は正しい日本語で書く。 主語をきちんと入れることが大事(〜のつもりで書いた、というのは知らない人には伝わらない)。 情報は多すぎず、少なすぎず。 条件について場合分けして整理したり、図を用いたりすると良い。 前提と制
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集が 長くなりすぎたので、組織運営に関する部分を別項目として独立させました。 ここに書いてあることを、組織運営を行っているリーダー以上の方は冷静に読んで欲しい。 組織運営に失敗すると、 優秀なエンジニアがいてもどうしようもないほどに開発速度の低下を引きおこす。 資金を投入して外部に開発を委託したものが、まったく使い物にならないことになる。 対外的な信頼をぶち壊しにすることができる。 優秀なエンジニアの心を、組織の開発目標から引き離してしまうことができる。 リーダーでない人もリーダーではないなりに組織運営に関わっている。 組織の運営に失敗して、成果の達成ができなければ不幸である。 1人1人のエンジニアの成長を実現できなければ不幸である。 不幸にしないための「べからず」を書いてみました。 自分たちの強みを何におくかを考えない。 仕事として開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
